TYPO3 14.3.5: Why Your Upload Limit in the Form Might Never Have Taken Effect

In short: TYPO3 14.3.5 LTS (July 14, 2026) fixes a vulnerability in the Form Framework where the configured upload limit was not enforced on the server side. Only versions 14.2.0 through 14.3.4 are affected. TYPO3 classifies this as a “Medium” vulnerability; it was not possible to upload PHP files. If you’re running TYPO3 14 with upload forms, update to 14.3.5.

Security alerts regarding a content management system (the system behind your website) can quickly sound like cause for alarm. This one is more low-key, yet still informative.

On July 14, 2026, the TYPO3 team reported a vulnerability in the Form Framework and patched it with an update. What’s interesting isn’t the severity level. What’s interesting is what went wrong: A security rule that many editors had actively enabled wasn’t enforced by the server at all. It looked like it was working. It wasn’t.

This post provides a level-headed analysis of the report. You’ll learn who’s affected, why “Medium” is the correct severity rating here, and what this case reveals about upload forms on any website.

What TYPO3 reported on July 14

The official advisory is titled TYPO3-CORE-SA-2026-020 (July 14, 2026). It affects the Form Framework, the form builder in the TYPO3 core. The vulnerability is tracked as CVE-2026-15305.

The gist in a nutshell: Forms with a FileUpload or ImageUpload field could be configured to allow only certain file types (the setting is called allowedMimeTypes). This restriction was not enforced on the server. According to the report, the responsible validator (the MimeTypeValidator) was registered too early, before the specific form settings took effect. It never made it into the processing phase.

This can be verified in the TYPO3 core itself: The commit to fix the issue is titled “Register MimeTypeValidator for file uploads at runtime.” Since then, the validator has been registered at runtime, meaning only after the specific form settings have been determined. If you want to know what a security update actually changed, you’ll find the answer in commits like these, not in the headline.

In practical terms, this means: A visitor could upload files with any MIME type (the identifier for the file format), including those that the editor had actually excluded.

This has been fixed in TYPO3 14.3.5 LTS. Versions 14.2.0 through 14.3.4 were affected. Anyone running TYPO3 13 or older is not affected by this issue.

How dangerous is this vulnerability for your company?

TYPO3 rates the vulnerability as “Medium.” This is not an understatement; it accurately reflects the actual risk.

The most important point from the security advisory: Uploading PHP files was not possible. PHP is the language on which TYPO3 runs. If an attacker could upload and execute a PHP file, that would be the classic way to take over a site. That’s exactly what was prevented here.

What remains is a minor issue: The server accepted file types that were not permitted according to the configuration. This can cause problems, such as inappropriate or unwanted files ending up in an upload folder. It’s not a direct path to taking control of the website. So there’s no reason to panic, but it’s a good reason to schedule the update.

This is what clear communication looks like, and it’s how you can assess a security alert: clearly defined severity, named risk, and defined scope of the risk. Anyone who instead declares every alert a catastrophe isn’t helping you assess the situation.

Why a restriction in the form alone isn’t enough

Here’s the instructive part, independent of TYPO3.

Imagine a contact form with file upload, such as for a job application with a resume or a request with a technical drawing. You specify: only PDFs and JPGs are allowed, nothing else. This rule must be enforced at a point where the visitor cannot bypass it. That’s the server, not the browser.

If only the browser (the visitor’s display) performs the check, the rule is merely a recommendation, not a barrier. Anyone who wants to can bypass the prompt and send their file directly to the server. If there’s no secondary check there, the file gets through.

That was precisely the cause: Although server-side validation was intended, it failed to materialize in the actual process. The vulnerability falls under CWE-351, where permitted and non-permitted file types are not reliably distinguished.

The rule for every website is therefore: An upload restriction only counts if the server enforces it. Anything before that is merely a convenience for honest users, not protection against dishonest ones.

Are you affected? Your 3-step check

Three steps are all it takes to get a clear diagnosis. For the first two, you’ll need access to the TYPO3 backend (the administration interface) or, in short, your service provider.

Step 1: Which TYPO3 version are you running?
The version is displayed in the top-right corner of the backend or in the “About TYPO3” module. If it’s between 14.2.0 and 14.3.4, your site is affected. If it’s running on version 13, 12, or older, you’re not affected by this vulnerability.

Step 2: Do you use upload fields in forms?
Only forms with a FileUpload or ImageUpload element are relevant here. A simple contact form without file upload is not affected by this issue. Application, inquiry, or complaint forms with file attachments, on the other hand, are affected.

Step 3: Update to 14.3.5.
The update fixes the root cause. As with any TYPO3 update, apply it to a test system first, then to the live site. If a service provider manages your site, a brief note stating that the version mentioned in this announcement is required is often sufficient.

If the version, forms, and update are all correct, the issue is resolved for you.

What we see time and again with upload forms

A candid word from real-world experience. We’ve been managing TYPO3 sites since 2007, ranging from association websites to multilingual corporate sites. File uploads in forms are a recurring weak point, and not just in TYPO3.

The pattern is almost always the same. Someone builds a form with an upload feature, sets the allowed file types, and considers the matter settled. From the outside, you can’t tell whether the server-side validation actually works. It works in everyday use: The honest applicant uploads their PDF, and everything’s fine.

A calm approach to this is unspectacular. First: Monitor security advisories from the system in use; for TYPO3, this is done via the official announcement list. Second: Install updates promptly instead of letting them pile up. Third: For forms with upload fields, periodically test the forms and upload fields to ensure the restriction is enforced on the server, not just in the browser.

This isn’t a major effort. It’s maintenance. And maintenance is the difference between a site that remains stable when such alerts occur and one that becomes a question mark every time.

If you’re unsure which version of TYPO3 your site is running on and whether your forms are affected, we can clarify that with a quick review.

→ Request a security check: Is my form upload currently secure?

Sources (as of July 23, 2026)

• TYPO3-CORE-SA-2026-020: Unrestricted File Upload in Form Framework (July 14, 2026)
• CVE-2026-15305 (CWE-351)
• TYPO3-Core-Commit 817ad41: Register MimeTypeValidator for file uploads at runtime
• TYPO3 14 Release Notes (Fixed in 14.3.5 LTS)
• TYPO3 Security Guide