Laravel's Default Email Rule Had a CRLF Injection Flaw (CVSS 8.9). Here Is What to Check.

An 8.9 in the framework's default email validation rule is an unusual thing to see, and the reason it scores that high is worth understanding before you decide how quickly to act.

The Laravel team published GHSA-5vg9-5847-vvmq on 1 June 2026. It covers CRLF injection reachable through the email validation rule, the one nearly every Laravel application uses without thinking about it. Affected versions are 13.0.0 through 13.9.0, and anything below 12.60.0. The patches are in 13.10.0 and 12.60.0.

No CVE identifier had been assigned when I last checked, so if you are searching your dependency scanner's output, search for the GHSA identifier rather than a CVE number.

Why an 8.9

The CVSS vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L. Two parts of that do the work.

PR:N means no privileges are required. The attacker does not need an account, because the entry point is any form that accepts an email address and eventually sends mail to it. That is your registration form.

S:C is the scope-changed flag, and it is what pushes the score into the high band despite AC:H marking the attack as complex. Scope changed means the impact lands outside the vulnerable component. The damage is not confined to your Laravel process, it reaches your mail transport and your recipients, which is a different blast radius from a bug that corrupts data inside your own application.

The high attack complexity is the mitigating factor and is real. This is not a trivially weaponised flaw. It is also not a reason to sit on it, because attack complexity describes the work required once, and that work only has to be done by one person before it is commoditised.

The mechanism, briefly

Email addresses are validated by the framework's email rule and then handed onwards to Symfony Mailer and Symfony Mime for actual delivery. The two layers disagreed about how to treat certain character sequences. Input that the validation layer accepted as a well-formed address could be interpreted by the mail layer as containing structure rather than just an address.

Email headers are newline-delimited. Anything that can smuggle a line break into a position where a header is being assembled can introduce additional headers. That is the entire CRLF injection family, and it has been a recurring theme in mail handling for twenty years. What is notable here is not the class of bug but where it appeared: the default path, in the framework, used by nearly everyone.

I am not publishing a payload. The advisory does not, the fix is available, and the mechanism above is enough to explain why you should care and enough for you to reason about your own exposure.

Check whether you are affected

The version you are running is not always the version in your composer.json constraint. Ask Composer directly, on the machine that actually serves production:

composer show laravel/framework | grep versions

Then compare against the affected ranges. Laravel 13.0.0 to 13.9.0 inclusive is affected, as is anything below 12.60.0.

Composer will also tell you about known advisories against your installed tree, which is the faster route if you have several packages to think about:

composer audit

This is the same command worth having in CI permanently, for reasons we went into in using Composer Audit to find vulnerable PHP packages.

Upgrading

For most applications this is a patch-level move within a supported branch, which is about as low-risk as framework upgrades get:

composer require laravel/framework:^13.10.0 --update-with-dependencies
# or, on the 12 branch
composer require laravel/framework:^12.61.1 --update-with-dependencies

I have used 12.61.1 rather than 12.60.0 deliberately. There is a second advisory affecting temporary signed URLs, GHSA-crmm-hgp2-wgrp, patched in 12.61.1 and 13.12.0, so if you are upgrading anyway you may as well clear both. We covered that one in your temporary signed URLs may not be expiring.

If you are on Laravel 11 or older, there is no patch for you. Those branches are outside the supported window, which means this advisory joins the set of things that will simply remain true about your application until you upgrade the framework. That is a larger project and worth scheduling honestly rather than deferring indefinitely.

What to check after patching

Upgrading closes the hole. It does not tell you whether anything happened before you closed it, and that is worth ten minutes.

Look at your mail transport logs for the affected period, and specifically for messages with recipient counts higher than your application would ever generate, or headers your templates do not set. Most application-level mail is highly uniform, which makes anomalies unusually visible if you look.

If you use a transactional provider such as Postmark, SES, or Mailgun, their sending logs are the better source, since they record what was actually accepted rather than what your application believed it sent. Check for bounces or suppressions against domains you have no users at.

Also worth confirming: whether your SPF and DMARC records are strict enough that a relayed message would have failed anyway. A lot of teams discover during this kind of review that DMARC is still on p=none, which means the policy is observing rather than protecting.

Defence in depth for next time

Three things that reduce the impact of the next mail-adjacent bug, none of which are a substitute for patching.

Sanitise control characters out of addresses before they reach the transport, at the boundary where the address enters your system rather than at the point of sending. This is a few lines in a form request and it costs nothing.

Use the stricter validation variants where the trade is acceptable. email:rfc,dns performs a DNS lookup and rejects domains that cannot receive mail, which also cuts a meaningful amount of signup abuse as a side effect.

Keep composer audit in CI as a failing check rather than an advisory one. The gap between an advisory being published and a team hearing about it is where most of the real risk in dependency management lives, and it is almost always a process gap rather than a technical one.

StackShield checks your application from the outside on a schedule and flags known-vulnerable framework versions along with the misconfigurations that make a bug like this easier to exploit. Run a free scan if you want to know what your production deployment is currently advertising about itself.