Statamic's file upload restrictions have a critical enforcement gap: restrictions you configure through the Control Panel only apply within authenticated admin workflows. Frontend forms—created by adding an asset field to a form—ignore these settings entirely. This isn't a missing validation check; it's a structural mismatch between where you configure restrictions and where they actually take effect.
The practical consequence: an administrator adds a files field to a frontend form, configures allowed types to exclude risky uploads, tests through the Control Panel interface where restrictions ARE enforced, and deploys believing the restrictions apply everywhere. They won't discover the bypass unless they specifically test unauthenticated upload flows—which is exactly the scenario where it matters. The configuration feels authoritative because it lives in the admin panel, but it's actually context-dependent enforcement that creates a false sense of security.
The vulnerability was patched in version 5.74.3 (Statamic 5.x) and 6.24.2 (Statamic 6.x). If you're on earlier versions, upgrade. More importantly: audit any frontend forms that accept file uploads. Check whether the field's allowed types configuration matches what you intend to permit from public-facing forms—do not assume Control Panel settings propagate to frontend contexts.
One mitigating factor: executable types like .php and .html remain blocked by a global allowlist regardless of context. So while administrators can't enforce their own custom restrictions on the frontend, the system still prevents truly dangerous file types. But this defense-in-depth shouldn't comfort you into complacency—the gap between what you configure and what actually gets enforced is exactly the kind of misconfiguration that creates persistent, discoverable artifacts on public storage that outlive the vulnerability itself.