When the Notification Email Trusts the Stranger: CVE-2026-71435 in Statamic
Hi, I’m a Penetration Tester. My job is to intentionally make applications do things they’re not supposed to—finding flaws and exploiting them to ensure they’re secure. I specialize in Web, API, Android, and iOS security.
Most XSS hunting fixates on the page the victim loads. But output rendering happens in more places than a browser window — and one of the easiest to forget is the notification email that fires when a stranger submits a form. The person who reads that email is usually staff. The person who filled the form is usually not. That asymmetry is where CVE-2026-71435 lives.
The target
Statamic is a flat-file CMS built on Laravel. Its forms feature has a convenience mode — the "automagic" notification — where you don't hand-write an email template; Statamic generates one for you from the submitted fields. It's the path of least resistance, which means it's the path a lot of sites are actually on.
The assumption that broke
The automagic notification template rendered user-submitted values without escaping. An unauthenticated visitor — anyone who can reach a public form — could put HTML (including script-bearing markup) into a field, and that markup would land, unescaped, in the notification email delivered to the configured recipients.
The implicit assumption was that the people building the form own both ends of it. In reality the input end is open to the public and the output end is staff-facing. Auto-generating the template quietly dropped the escaping step that a hand-written, security-aware template might have included.
What it actually affected
Here's where I stay disciplined, because the advisory is: this is stored HTML/script injection into form notification emails rendered from unescaped submitter input. The CVSS vector is AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (6.1, Moderate) — note UI:R (a recipient has to open/render the message) and S:C (the injection crosses from the untrusted submitter into the recipient's context). The advisory did not publish a proof of concept, and I'm not going to invent one or assert a specific downstream exploit (credential theft, pivot, etc.) that wasn't demonstrated. The proven fact is the injection primitive and where it renders; that is enough to warrant the fix and the CVE.
What makes it notable isn't exotic technique — it's reach. The attacker needs no account, no interaction from the submitter beyond submitting, and the content is delivered straight to the inbox of whoever administers the site.
The fix
Escape user-submitted values in the automagic notification template so submitter input is rendered as text, not markup. Statamic shipped the fix in:
5.74.3 (for the 5.x line), and
6.24.2 (for 6.x; affected from 6.0.0).
The lesson
Enumerate every sink, not just the browser. A single piece of user input can be rendered into a web page, a PDF, a log viewer, a Slack webhook, and an email — and "we escape on the website" says nothing about the other four. Email is an especially sharp one because the audience inverts: the untrusted party writes it, the trusted party reads it.
And watch the "automagic"/scaffolded paths in any framework. Convenience generators optimize for working, and escaping is invisible when it's present and invisible when it's missing. The default template is exactly where a missing e()/{{{ }}}-vs-{{ }} decision hides in plain sight.
Disclosure
Reported by @ya3raj; published by @jasonvarga.
Advisory: GHSA-vx89-p3j7-8xqc · CVE-2026-71435
Fix: statamic/cms#14959, commit
4ad1335, releases v5.74.3 and v6.24.2