GHSA-2r6j-862c-m2v2 — typo3/cms-form
HIGHGHSA-2r6j-862c-m2v2 is a high-severity (CVSS 8.6) Unrestricted File Upload vulnerability in typo3/cms-form. A fix is available for typo3/cms-form — see the affected versions and patch details below.
Unrestricted File Upload in Form Framework
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2r6j-862c-m2v2 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
typo3/cms-form🐘typo3/cms-form🐘typo3/cms-form🐘typo3/cms-form🐘typo3/cms-core🐘typo3/cms-core🐘typo3/cms-core🐘typo3/cms+2 moreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Problem
Due to the lack of ensuring file extensions belong to configured allowed mime-types, attackers can upload arbitrary data with arbitrary file extensions - however, default fileDenyPattern successfully blocked files like .htaccess or malicious.php.
TYPO3 Extbase extensions, which implement a file upload and do not implement a custom TypeConverter to transform uploaded files into FileReference domain model objects are affected by the vulnerability as well, since the UploadedFileReferenceConverter of ext:form handles the file upload and will accept files of any mime-type which are persisted to the default location.
In any way, uploaded files are placed in the default location /fileadmin/user_upload/, in most scenarios keeping the submitted filename - which allows attackers to directly reference files, or even correctly guess filenames used by other individuals, disclosing this information.
No authentication is required to exploit this vulnerability.
Solution
Update to TYPO3 versions 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.
Type converter UploadedFileReferenceConverter is not registered globally anymore and just handles uploaded files within the scope of the Form Framework. Guessable storage location has changed from /fileadmin/user_upload/form_<random-hash>/ to /fileadmin/form_uploads/<random-40-bit>. Allowed mime-types must match expected file extensions (e.g. application/pdf must be .pdf, and cannot be .html).
Extbase extensions, who rely on the global availability of the UploadedFileReferenceConverter must now implement a custom TypeConverter to handle file uploads or explicitly implement the ext:form UploadedFileReferenceConverter with appropriate setting for accepted mime-types.
Credits
Thanks to Sebastian Michaelsen, Marc Lindemann, Oliver Eglseder, Markus Volkmer, Jakob Kunzmann, Johannes Regner, Richie Lee who reported this issue, and to TYPO3 core & security team members Oliver Hader & Benni Mack, as well as TYPO3 contributor Ralf Zimmermann who fixed the issue.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | typo3/cms-form | ≥ 8.0.0&&< 8.7.40 | 8.7.40composer require typo3/cms-form:^8.7.40 |
| 🐘Packagist | typo3/cms-form | ≥ 9.0.0&&< 9.5.25 | 9.5.25composer require typo3/cms-form:^9.5.25 |
| 🐘Packagist | typo3/cms-form | ≥ 10.0.0&&< 10.4.14 | 10.4.14composer require typo3/cms-form:^10.4.14 |
| 🐘Packagist | typo3/cms-form | ≥ 11.0.0&&< 11.1.1 | 11.1.1composer require typo3/cms-form:^11.1.1 |
| 🐘Packagist | typo3/cms-core | ≥ 10.0.0&&< 10.4.14 | 10.4.14composer require typo3/cms-core:^10.4.14 |
| 🐘Packagist | typo3/cms-core | ≥ 11.0.0&&< 11.1.1 | 11.1.1composer require typo3/cms-core:^11.1.1 |
Affected Products
typo3typo3Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for typo3/cms-form, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update typo3/cms-form to 8.7.40 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2r6j-862c-m2v2 is resolved across your whole dependency graph.
Workarounds
Treat uploaded files as untrusted until proven otherwise: validate the actual content type rather than the supplied extension, store uploads outside the web root on a volume mounted without execute permission, and rename them to server-generated identifiers so an attacker cannot choose the path a request will later resolve.
Frequently Asked Questions
Is GHSA-2r6j-862c-m2v2 in your dependencies?
Find it across Packagist, including transitive dependencies.