TYPO3 SA-2026-020 (CVE-2026-15305): the Form Framework's MimeTypeValidator was never registered — fixed in 14.3.5

TL;DR — 90 seconds

Affected?

TYPO3 14.2.0 through 14.3.4 with ext:form forms that use FileUpload or ImageUpload elements with an allowedMimeTypes restriction. TYPO3 13.4 LTS (including 13.4.33) is not affected per the advisory.

Risk?

CVSS 4.0 (Medium): the MimeTypeValidator was registered while the form was being built, before the concrete form definition was applied, so it never made it into the active processing pipeline. Users could upload files of any MIME type even though the form only allowed specific types. PHP uploads stayed blocked through a separate check — no direct RCE has been demonstrated via this path.

Immediate action?

Update to 14.3.5: composer require typo3/cms-form:^14.3.5 typo3/cms-core:^14.3.5. No database update needed, clear the cache.

Recommendation?

Anyone running 14.2.x/14.3.x with production Form Framework uploads should patch in the next regular maintenance window. Given CVSS 4.0 and PHP execution staying blocked, no emergency rollout is needed — but it's not something to sit on indefinitely either.

Criticality?

medium — limited blast radius (no RCE, narrow version window), but core-relevant, easy to exploit, and easy to fix.

What is the problem?

The TYPO3 Form Framework (ext:form) lets you configure an allowedMimeTypes restriction for FileUpload and ImageUpload elements in a form's YAML definition — for example “PDF only” or “JPEG/PNG only“. Technically this restriction is enforced by a MimeTypeValidator that is supposed to run when the uploaded element is processed.

CVE-2026-15305 describes a timing bug in form construction: the MimeTypeValidator was registered while the form object itself was being built — at a point where the concrete form definition (including the site-specific allowedMimeTypes configuration) had not yet been applied to the element. As a result, the validator never made it into the processing pipeline that actually runs when the form is submitted. The upshot: whatever MIME-type restriction the site owner had configured simply wasn't enforced, regardless of what was set in the form definition.

Important context: a separate check, independent of this validator, continues to block PHP files from being uploaded this way. The bug does not open a direct path to server-side code execution through the PHP interpreter — it only defeats the type allowlist itself.

Who is affected?

The advisory makes no explicit statement about 14.0 and 14.1 — both lines are end-of-life regardless and receive no maintenance, so moving to 14.3.5 is the only supported path either way.

Impact

The immediate effect is a silent bypass of the MIME-type allowlist: where a form was meant to allow “PDF only,” TYPO3 effectively accepted any file type. Because PHP files stay blocked separately, no direct remote code execution via this path has been demonstrated — the CVSS 4.0 rating (Confidentiality: none, Integrity: low, Availability: low) reflects that limited direct impact.

The practical risk depends heavily on how the target upload directory is configured and served: if an uploaded HTML or SVG file later gets rendered inline in the browser instead of being forced to download, stored XSS becomes a realistic scenario — SVG files can contain embedded JavaScript that executes on inline rendering. Downstream processing errors are also plausible, where systems further down the pipeline (image processing, virus scanning, conversion pipelines) receive file types they weren't built to handle. Wherever operators relied solely on the form-side MIME-type check as their protection, that protection was effectively inert.

Mitigation / immediate steps

Operational decision block

• Act now if … you run production, publicly reachable upload forms with a MIME-type restriction on 14.2.x–14.3.4.
• Check with priority if … you run a multi-site installation with many ext:form instances — every form definition with an upload element is a potential hit.
• Next regular window if … you don't run public upload forms, or you're already on 13.4 LTS.

Step 1 — update to 14.3.5

# check current version
vendor/bin/typo3 --version
composer show typo3/cms-form

# update
composer require typo3/cms-form:"^14.3.5" typo3/cms-core:"^14.3.5"
# or more broadly:
composer update typo3/cms-* --with-dependencies

# clear cache (no DB update required)
vendor/bin/typo3 cache:flush

Step 2 — harden upload directories regardless of the patch

# make sure upload target directories can never execute scripts
# (example Apache .htaccess in the upload target folder):
# <filesmatch>
#   Require all denied
# </filesmatch>

# example nginx: block execution in the upload path
# location ^~ /fileadmin/form_uploads/ { fastcgi_pass off; }

# force downloads instead of inline rendering (prevents SVG/HTML stored XSS)
# Content-Disposition: attachment; X-Content-Type-Options: nosniff

This server-side hardening is worthwhile independent of the patch — the incident shows that form-side MIME-type checking alone is not a reliable security boundary.

Detection / verification

Check version

vendor/bin/typo3 --version
composer show typo3/cms-form typo3/cms-core

Check form definitions for affected upload elements

# search form YAML definitions for FileUpload/ImageUpload
grep -rl "type: FileUpload\|type: ImageUpload" fileadmin/ typo3conf/ 2>/dev/null

# list configured allowedMimeTypes per form
grep -A3 "allowedMimeTypes" fileadmin/*/Form*.yaml 2>/dev/null

Check upload target directories for unexpected file types

# example: search a target folder for file types outside an expected list
find fileadmin/form_uploads/ -type f ! -iname "*.pdf" ! -iname "*.jpg" ! -iname "*.png" -print

# verify file type via magic bytes rather than extension
find fileadmin/form_uploads/ -type f -exec file {} \;

Since the bug is purely in validation logic and doesn't enable execution, there are no specific runtime indicators of active exploitation — the check mainly serves to identify and assess files already uploaded outside the intended allowlist.

Operator guidance

Mid-market

Update to 14.3.5 in the next regular maintenance window. No emergency rollout needed — CVSS 4.0 and PHP execution staying blocked don't justify a weekend special.

Enterprise / multi-site

Audit all ext:form YAML definitions with upload elements and document where allowedMimeTypes was relied on as the sole protection. Add server-side hardening of upload target directories (no script execution, forced downloads) independent of the patch — this incident is a clear example of why client-/form-side validation should never be the only line of defense.

TYPO3 agencies with client projects

Since only 14.2.x/14.3.x are affected, it's worth a quick check of which client installations have already moved to 14 — the 13.4 LTS majority is off the hook here. The CVE reference still belongs in the next maintenance note so the update is documented.

Decision block

Act today if: public upload forms relying on MIME restriction as a security control are live on 14.2–14.3.4. Regular window if: no upload elements in use, or already on 13.4 LTS.

Conclusion

CVE-2026-15305 isn't a dramatic bug — CVSS 4.0, no RCE, a narrow window of just two 14.x minor releases. That's exactly what makes it a good teaching example: the fault isn't missing validation logic, it's the order in which validators are wired up inside the Form Framework's construction pipeline — a class of bug that's easy to miss in complex object-construction pipelines and stays silent until someone specifically goes looking for it. Anyone who used form-side MIME-type checking as the sole line of defense for file uploads should take this incident as a reason to add server-side control over execution and delivery of uploaded files — independent of the TYPO3 patch level.

Sources

• TYPO3 — TYPO3-CORE-SA-2026-020: Unrestricted File Upload in Form Framework (14 Jul 2026)
• TYPO3 News — Security Advisories Overview
• wwagner.net — TYPO3 14.3.5 Fixes a Security Vulnerability in the Form Framework