Laravel Email Rule: Header Injection Into Outgoing Mail

Published as "Laravel Framework: CRLF injection in default email rule"

high Laravel Laravel framework · Last reviewed Nov 7, 2026

CVE: No CVE assigned
GHSA: GHSA-5vg9-5847-vvmq
Packagist: PKSA-3r5d-mb8f-1qw9
Reported: Jun 17, 2026

Lets an unauthenticated attacker interfere with outgoing email in Laravel apps that send mail to addresses users supply.

Affected and fixed versions

In laravel/framework. Find the row for the version you run, and update to the release next to it.

If you run	Update to	Support
13.0.0 – 13.9.0	No fix yet	Supported
Up to 12.59.x	12.60.0	Supported

Upgrade

Run the line for the branch you are on.

composer require laravel/framework:^12.60.0

What this means

Laravel's email validation rule accepted addresses that contain line breaks. Combined with how Symfony Mailer and Symfony Mime handle those addresses, an attacker who can enter an email address may be able to change the content of mail your app sends, have it delivered to other recipients, or make your mail server send messages it shouldn't.

No account is needed when the address comes from a public form. See the Laravel advisory and the fix.

Who is affected

Apps on an affected version that validate a user-supplied address with the email rule and then send mail to it. Common places are registration, password reset, email verification and contact forms.

How much harm is possible depends on what your app sends by email and how your mail server is set up. Apps that never send mail to addresses users enter aren't exposed.

What to do

Update laravel/framework to 12.60.0 on 12.x or 13.10.0 on 13.x.

The fix makes the email rule fail for values with line breaks. It also makes Laravel's mailer refuse any address containing a line break, so mail sent to addresses that never went through validation is covered too.

Reported by OmarXtream.

Check your app with an agent

Paste this into a coding agent that can read your project, such as Claude Code, Codex or Amp. It checks your composer.lock against the versions above and tells you what to update, without changing anything.

Check whether the PHP project you have access to is affected by this security advisory, and tell me what to update. Do a read-only check: don't edit files, don't run composer update or composer require, and don't try to reproduce the flaw.

Advisory: Laravel Email Rule: Header Injection Into Outgoing Mail (GHSA-5vg9-5847-vvmq)
Details: https://phpnews.net/security/laravel/ghsa-5vg9-5847-vvmq

Affected versions, as Composer constraints:
- laravel/framework: <12.60.0|>=13.0.0,<=13.9.0

Fixed releases on branches that still get security fixes:
- 13.0.0 – 13.9.0: no fixed release yet
- Up to 12.59.x: update to 12.60.0

1. Find every composer.lock in the project outside vendor/ (a monorepo can have one per app) and read the installed version of each package above. Packages installed as dependencies of other packages count too.
2. Compare each installed version with its constraint: "|" separates alternative ranges, and "," means both bounds apply.
3. For each affected install, read "What this means" at https://phpnews.net/security/laravel/ghsa-5vg9-5847-vvmq and check whether the project meets the conditions it describes (a feature in use, a config value, a driver). Say which conditions you could check and which you couldn't.
4. Report a table: lock file | package | installed version | affected (yes, no or unknown) | conditions met (yes, no or unknown) | update to | evidence. For each affected package, give the command that would fix it, without running it: composer update <package> --with-dependencies when it is only installed as a dependency of another package, or composer require with the fixed version when composer.json requires it directly. If the installed version is on a branch with no fixed release listed, say it needs a move to a newer branch.

Sources

GitHub advisory GHSA-5vg9-5847-vvmq →

← All Laravel advisories