TL;DR — Six vulnerabilities in Statamic, a Laravel-based flat-file CMS. The headline bug: Antlers-enabled control panel inputs allow authenticated users to achieve remote code execution. Supporting bugs include an open redirect via URL parsing differential, reflected XSS in password reset, sensitive config exposure through template fields, content protection bypass via preview tokens, and missing authorization on revision endpoints. Together they form an escalation path from unauthenticated visitor to full server compromise.

background

Statamic is a flat-file CMS built on Laravel. It's popular with agencies and developers who want content management without a database — everything is stored in YAML and Markdown files on disk. The project has a loyal following and powers thousands of production sites.

What makes Statamic architecturally interesting (and dangerous) is its template engine: Antlers. Antlers templates can evaluate expressions, access Laravel's configuration values, call modifiers and tags, and in some contexts execute PHP functions. This is intentional — it makes the template engine powerful enough to build complex sites without custom code.

The problem is when user-controlled input reaches the Antlers engine. Antlers doesn't distinguish between "template code from a trusted .html file" and "text a content editor typed into a field." If the field has Antlers processing enabled, anything in it gets evaluated.

bug 1: open redirect (CVE-2026-33885)

Several unauthenticated Statamic endpoints accept a redirect parameter that controls where the user is sent after an action. The URL is validated by one parser and followed by another, and they disagree on what constitutes a valid URL.

The validation layer sees https://statamic.test/dashboard and considers it safe — it's on the same domain. The redirect handler interprets the same input differently due to a URL parsing differential and follows it to https://attacker.com. The specifics depend on character encoding and path normalization differences between the two components.

On its own, an open redirect is low severity. But it's the entry point for what comes next.

bug 2: reflected XSS in password reset (CVE-2026-33883)

The password reset form tag includes a redirect parameter in its output. This parameter is reflected into the page without escaping. The template renders the raw value from the URL into an HTML attribute:

<input type="hidden" name="redirect" value="ATTACKER_CONTROLLED">

By crafting a password reset URL with a malicious redirect value containing JavaScript, an attacker gets script execution in the context of the Statamic domain. The victim receives a legitimate-looking password reset link (from the real Statamic domain), clicks it, and the XSS fires.

Combined with the open redirect, the attacker can both execute JavaScript and redirect the victim afterward, making the attack nearly invisible.

bug 3: sensitive config exposure (CVE-2026-33886)

This is where things get interesting. Content editors — users with permission to create and modify entries — can access fields that have Antlers processing enabled. These fields evaluate template expressions before rendering.

A content editor enters this in an Antlers-enabled field:

{{ config:app:key }}

Statamic evaluates it and returns Laravel's APP_KEY — the secret used for:

  • Encrypting session cookies
  • Signing CSRF tokens
  • Encrypting any data stored with Laravel's encrypt() helper

With the APP_KEY, an attacker can forge session cookies to impersonate any user, including administrators. They can also decrypt any encrypted values in the application, which may include API keys, database credentials, or other secrets stored via Laravel's encryption.

Other useful config values accessible through Antlers:

{{ config:database:connections:mysql:password }}
{{ config:mail:mailers:smtp:password }}
{{ config:services:stripe:secret }}

Any configuration value that Laravel can access is readable through an Antlers-enabled field.

bug 4: content protection bypass (CVE-2026-33884)

Statamic supports content protection — marking entries as restricted so they require authentication or special access to view. The live preview feature generates tokens that bypass this protection, allowing editors to preview protected content before publishing.

The authorization check verifies that the preview token is valid but doesn't verify that the token was generated for the specific entry being accessed. A valid preview token for entry A grants access to protected entries B, C, and D. Any editor with preview access to any entry can read all protected content on the site.

bug 5: missing authorization on revisions (CVE-2026-33887)

Statamic tracks revision history for entries. The revision controllers don't check whether the authenticated user has permission to access a given entry's revision history. Any authenticated control panel user — regardless of their role or permissions — can read the full revision history of any entry on the site.

This includes draft content, deleted paragraphs, previous versions of sensitive pages, and any data that was edited and then removed. The revision history is a shadow copy of everything that was ever written.

bug 6: remote code execution (CVE-2026-28425)

The core vulnerability. Antlers-enabled inputs in the control panel don't just evaluate safe template expressions — they can execute arbitrary PHP code. An authenticated user with access to any Antlers-enabled input can inject template syntax that calls PHP functions:

The affected inputs include content fields with Antlers enabled, form email notification settings, and third-party addon fields (like SEO Pro).

The advisory notes that initial fixes in versions 5.73.11 and 6.4.0 were bypassed — the researcher found techniques to circumvent the first round of restrictions, requiring a second patch cycle. This suggests the Antlers evaluation surface is complex enough that simple blocklisting is insufficient.

the chain

An attacker can compose these bugs into a full compromise path:

Step Bug Starting Access Resulting Access
1 Open redirect None Phishing entry point
2 Reflected XSS None JavaScript in victim's session
3 XSS → session XSS Authenticated as content editor
4 Config exposure Content editor Laravel APP_KEY
5 Forge session APP_KEY Administrator session
6 RCE via Antlers Administrator Server-level code execution

Not every step is required. If the attacker already has any authenticated access to the control panel, bugs 3 and 6 take them straight from content editor to RCE. The open redirect and XSS are only needed for the initial foothold.

the fix

Statamic 5.73.16 and 6.7.2 address all six vulnerabilities:

  • URL validation and redirect handling now use consistent parsing, closing the open redirect
  • The redirect parameter is properly escaped in form output, preventing XSS
  • Antlers evaluation in control panel inputs is restricted to a safe subset of operations
  • Preview token authorization validates the token against the specific entry being accessed
  • Revision controllers enforce per-entry permission checks

what this reveals

Template engines that can execute code create a permanent security boundary: everything on one side is code, everything on the other side is data. Antlers intentionally blurs this boundary to make content management more powerful. That's a valid design choice, but it means every input that touches the template engine must be treated as a potential code execution vector.

The first patch being bypassed is telling. When the template engine is designed to be powerful, restricting it after the fact is a game of whack-a-mole. The fix needs to happen at the architectural level — either sandboxing the engine or ensuring untrusted input never reaches it.

CVE-2026-28425, CVE-2026-33883, CVE-2026-33884, CVE-2026-33885, CVE-2026-33886, CVE-2026-33887. Fixed in Statamic 5.73.16 and 6.7.2.