# Two Doors, One Lock: CVE-2026-71434 in Statamic

When an application enforces a rule in one place, the attacker's first question is: *where else does the same action happen, and does the rule follow it there?* Validation that lives on the admin door tells you nothing about the public door into the same room. CVE-2026-71434 is what happens when those two doors don't share a lock.

## The target

[Statamic](https://statamic.com/) lets site builders expose public frontend forms with `assets` or `files` fields, so visitors can upload attachments. The same uploads also happen through the Control Panel (the admin UI), which enforces per-field file-type restrictions an administrator configures.

## The assumption that broke

The Control Panel enforced those upload restrictions. The public frontend forms **did not**. So the allowed-types rule an administrator set up — intending it to apply to the feature as a whole — was really only guarding the admin path. An unauthenticated visitor hitting the frontend form could upload file types the administrator had intended to disallow, and those files could reach publicly accessible storage.

The mental model error is a common one: treating a validation rule as a property of the *feature* when it's actually a property of one *code path*. The rule was written once, near the Control Panel, and the frontend path grew up without inheriting it.

## What it actually affected — and the limit that kept it Moderate

This is the part worth being precise about, because it's where overclaiming would be easy and wrong.

The bug lets an unauthenticated visitor bypass the **per-field, administrator-configured** allowlist on frontend forms. It does **not** defeat Statamic's **global** upload allowlist: executable types such as `.php` and `.html` remained blocked. So this is not a path to a web shell or stored XSS via an uploaded `.html` — the advisory explicitly says those stayed blocked, and I'm not going to imply otherwise.

That limit is exactly why the vector is `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N` (5.3, Moderate): network-reachable, no auth, no interaction, but only a *low integrity* impact — disallowed-but-non-executable files reaching storage — with no confidentiality or availability loss. CWE-434, scoped honestly.

## The fix

Make the frontend form path enforce the same upload restrictions the Control Panel does, so the per-field allowlist applies regardless of which door the upload comes through. Fixed in:

*   **5.74.3** (5.x line), and
    
*   **6.24.2** (6.x; affected from 6.0.0).
    

## The lesson

For any sensitive operation, inventory every entry point before you trust the control: admin UI, public form, REST/GraphQL API, CLI, import jobs. Then verify the control sits *below* all of them — ideally in the shared service that performs the action — not bolted onto a single front end. A rule enforced per-path is a rule you will eventually forget to copy onto the next path.

And when you report one of these, report the ceiling too. "Frontend forms skip the per-field allowlist, but the global allowlist still blocks executables" is a stronger, more credible finding than a vague "arbitrary file upload" that a triager can disprove in thirty seconds.

* * *

**Disclosure**

*   Reported by [@ya3raj](https://github.com/ya3raj).
    
*   Advisory: [GHSA-qhr7-v3xp-vw9m](https://github.com/advisories/GHSA-qhr7-v3xp-vw9m) · CVE-2026-71434
    
*   Fix: [statamic/cms#14958](https://github.com/statamic/cms/pull/14958), commit `8be7b6c`, releases v5.74.3 and v6.24.2