TYPO3 SA-2026-020 (CVE-2026-15305): Der MimeTypeValidator im Form Framework wurde nie registriert — Fix in 14.3.5

TL;DR — 90 Sekunden

Betroffen?

TYPO3 14.2.0 bis 14.3.4 mit ext:form-Formularen, die FileUpload- oder ImageUpload-Elemente mit allowedMimeTypes-Restriktion einsetzen. TYPO3 13.4-LTS (inkl. 13.4.33) ist laut Advisory nicht betroffen.

Risiko?

CVSS 4.0 (Medium): Der MimeTypeValidator wurde beim Form-Bau registriert, bevor die konkrete Formulardefinition angewendet wurde, und landete dadurch nie in der aktiven Verarbeitungs-Pipeline. Nutzer konnten Dateien mit beliebigem MIME-Type hochladen, obwohl im Formular nur bestimmte Typen erlaubt waren. PHP-Uploads blieben durch eine separate Sperre blockiert — keine direkte RCE über diesen Weg belegt.

Sofortmaßnahme?

Auf 14.3.5 aktualisieren: composer require typo3/cms-form:^14.3.5 typo3/cms-core:^14.3.5. Kein Datenbank-Update nötig, Cache leeren.

Empfehlung?

Wer 14.2.x/14.3.x mit produktiven Form-Framework-Uploads betreibt, patcht im nächsten regären Wartungsfenster. Angesichts CVSS 4.0 und weiterhin blockierter PHP-Ausführung ist kein Notfall-Rollout nötig — aber auch kein Grund zum Aussitzen.

Kritikalität?

medium — begrenzter Blast-Radius (kein RCE, schmales Versionsfenster), aber TYPO3-Core-relevant, leicht auszunutzen und leicht zu beheben.

Was ist das Problem?

Das TYPO3 Form Framework (ext:form) erlaubt es, in der YAML-Definition eines Formulars für FileUpload- und ImageUpload-Elemente eine allowedMimeTypes-Restriktion zu konfigurieren — zum Beispiel „nur PDF“ oder „nur JPEG/PNG“. Diese Restriktion wird technisch durch einen MimeTypeValidator durchgesetzt, der beim Verarbeiten des hochgeladenen Elements geprüft werden soll.

CVE-2026-15305 beschreibt einen Timing-Fehler in der Formular-Konstruktion: Der MimeTypeValidator wurde bereits beim Aufbau des Formularobjekts registriert — zu einem Zeitpunkt, an dem die konkrete Formulardefinition (inklusive der site-spezifischen allowedMimeTypes-Konfiguration) noch nicht auf das Element angewendet worden war. Dadurch landete der Validator nie in der tatsächlich aktiven Verarbeitungs-Pipeline, die beim Absenden des Formulars durchlaufen wird. Das Resultat: Die im Formular konfigurierte MIME-Type-Restriktion wurde schlicht nicht durchgesetzt, unabhängig davon, was der Betreiber in der Formulardefinition eingetragen hatte.

Wichtig zur Einordnung: Eine separate, von diesem Validator unabhängige Sperre verhindert weiterhin, dass PHP-Dateien auf diesem Weg hochgeladen werden können. Die Lücke ermöglicht also keinen direkten Weg zu serverseitiger Code-Ausführung über den PHP-Interpreter — sie hebelt ausschließlich die Typ-Allowlist selbst aus.

Wer ist betroffen?

Zu 14.0 und 14.1 macht das Advisory keine explizite Aussage — beide Versionslinien sind ohnehin End-of-Life und erhalten keine Wartung mehr, ein Wechsel auf 14.3.5 ist der einzig unterstützte Pfad.

Auswirkungen

Der unmittelbare Effekt ist ein stiller Bypass der MIME-Type-Allowlist: Wo ein Formular etwa „nur PDF“ erlauben sollte, akzeptierte TYPO3 faktisch jeden Dateityp. Da PHP-Dateien separat blockiert bleiben, ist keine direkte Remote-Code-Execution über diesen Weg belegt — die CVSS-4.0-Bewertung (Confidentiality: none, Integrity: low, Availability: low) spiegelt diesen begrenzten direkten Impact wider.

Das praktische Risiko hängt stark davon ab, wie das Zielverzeichnis für Uploads konfiguriert und ausgeliefert wird: Wird eine hochgeladene HTML- oder SVG-Datei später inline im Browser gerendert statt als Download erzwungen zu werden, ist Stored-XSS ein realistisches Szenario — SVG-Dateien können eingebettetes JavaScript enthalten, das beim inline-Rendering ausgeführt wird. Ebenso denkbar sind Downstream-Verarbeitungsfehler, wenn nachgelagerte Systeme (Bildverarbeitung, Virenscanner, Umwandlungs-Pipelines) unerwartete Dateitypen erhalten, auf die sie nicht vorbereitet sind. Wo Betreiber sich ausschließlich auf die Formular-seitige MIME-Type-Prüfung als Schutzmechanismus verlassen haben, war dieser Schutz faktisch wirkungslos.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie produktive, öffentlich erreichbare Formulare mit Datei-Upload und MIME-Type-Restriktion auf 14.2.x–14.3.4 betreiben.
• Mit Priorität prüfen, wenn … Sie eine Multi-Site-Installation mit vielen ext:form-Instanzen betreiben — jede Formulardefinition mit Upload-Element ist potenziell betroffen.
• Im nächsten regulären Fenster, wenn … Sie keine öffentlichen Upload-Formulare einsetzen oder bereits auf 13.4-LTS sind.

Schritt 1 — auf 14.3.5 aktualisieren

# aktuelle Version prüfen
vendor/bin/typo3 --version
composer show typo3/cms-form

# aktualisieren
composer require typo3/cms-form:"^14.3.5" typo3/cms-core:"^14.3.5"
# bzw. breiter:
composer update typo3/cms-* --with-dependencies

# Cache leeren (kein DB-Update nötig)
vendor/bin/typo3 cache:flush

Schritt 2 — Upload-Verzeichnisse absichern, unabhängig vom Patch

# sicherstellen, dass Upload-Zielverzeichnisse keine Skripte ausführen können
# (Beispiel Apache .htaccess im Upload-Zielordner):
# <filesmatch>
#   Require all denied
# </filesmatch>

# Beispiel nginx: Ausführung im Upload-Pfad unterbinden
# location ^~ /fileadmin/form_uploads/ { fastcgi_pass off; }

# erzwungene Downloads statt Inline-Rendering (verhindert SVG/HTML-Stored-XSS)
# Content-Disposition: attachment; X-Content-Type-Options: nosniff

Diese serverseitige Absicherung ist unabhängig vom Patch sinnvoll — der Vorfall zeigt, dass eine Formular-seitige MIME-Type-Prüfung allein keine verlässliche Sicherheitsgrenze ist.

Detection / Prüfung

Version prüfen

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

Formulardefinitionen auf betroffene Upload-Elemente prüfen

# Form-YAML-Definitionen nach FileUpload/ImageUpload durchsuchen
grep -rl "type: FileUpload\|type: ImageUpload" fileadmin/ typo3conf/ 2>/dev/null

# konfigurierte allowedMimeTypes je Formular auflisten
grep -A3 "allowedMimeTypes" fileadmin/*/Form*.yaml 2>/dev/null

Upload-Zielverzeichnisse auf unerwartete Dateitypen prüfen

# Beispiel: Zielordner auf Dateitypen außerhalb einer erwarteten Liste durchsuchen
find fileadmin/form_uploads/ -type f ! -iname "*.pdf" ! -iname "*.jpg" ! -iname "*.png" -print

# Datei-Typen (Magic Bytes statt Dateiendung) gegenprüfen
find fileadmin/form_uploads/ -type f -exec file {} \;

Da die Lücke reine Validierungslogik betrifft und keine Ausführung ermöglicht, gibt es keine spezifischen Laufzeit-Indikatoren für aktive Ausnutzung — die Prüfung dient vor allem dazu, bereits hochgeladene, außerhalb der eigentlich konfigurierten Allowlist liegende Dateien zu identifizieren und zu bewerten.

Betreiberempfehlung

Mid-Market

Auf 14.3.5 im nächsten regulären Wartungsfenster aktualisieren. Kein Notfall-Rollout nötig — CVSS 4.0 und weiterhin blockierte PHP-Ausführung rechtfertigen keine Wochenend-Sonderaktion.

Enterprise / Multi-Site

Alle ext:form-YAML-Definitionen mit Upload-Elementen auditieren und dokumentieren, wo allowedMimeTypes als alleinige Schutzmaßnahme eingesetzt wurde. Serverseitige Absicherung der Upload-Zielverzeichnisse (keine Skriptausführung, erzwungene Downloads) unabhängig vom Patch nachziehen — dieser Vorfall zeigt exemplarisch, warum Client-/Formular-seitige Validierung niemals die einzige Verteidigungslinie sein sollte.

TYPO3-Agenturen mit Kundenprojekten

Da nur 14.2.x/14.3.x betroffen sind, lohnt sich ein kurzer Abgleich, welche Kundeninstallationen bereits auf 14 gewechselt sind — die 13.4-LTS-Mehrheit ist hier fein raus. Die CVE-Referenz gehört trotzdem in die nächste Wartungsnotiz, damit die Mitnahme dokumentiert ist.

Entscheidungsblock

Heute handeln, wenn: öffentliche Upload-Formulare mit MIME-Restriktion als Sicherheitskontrolle auf 14.2–14.3.4 produktiv sind. Reguläres Fenster, wenn: keine Upload-Elemente im Einsatz oder bereits auf 13.4-LTS.

Fazit

CVE-2026-15305 ist keine dramatische Lücke — CVSS 4.0, kein RCE, ein schmales Versionsfenster von nur zwei 14er-Minor-Releases. Genau das macht sie zu einem guten Lehrstück: Der Fehler liegt nicht in fehlender Validierungslogik, sondern in der Reihenfolge, in der Validatoren im Form Framework aufgebaut werden — eine Klasse von Bugs, die in komplexen Objekt-Konstruktions-Pipelines leicht übersehen wird und still bleibt, bis jemand gezielt danach sucht. Wer Formular-seitige MIME-Type-Prüfung als alleinige Verteidigungslinie für Datei-Uploads eingesetzt hat, sollte diesen Vorfall zum Anlass nehmen, serverseitige Kontrolle über Ausführung und Auslieferung hochgeladener Dateien nachzuziehen — unabhängig vom TYPO3-Patch-Stand.

Quellen

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