GHSA-2r6j-862c-m2v2
HIGHGHSA-2r6j-862c-m2v2 is a high-severity (CVSS 8.6) Unrestricted File Upload vulnerability in typo3/cms-form. O3 Security confirms whether GHSA-2r6j-862c-m2v2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Unrestricted File Upload in Form Framework
Blast Radius
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.40 |
| 🐘Packagist | typo3/cms-form | ≥ 9.0.0&&< 9.5.25 | 9.5.25 |
| 🐘Packagist | typo3/cms-form | ≥ 10.0.0&&< 10.4.14 | 10.4.14 |
| 🐘Packagist | typo3/cms-form | ≥ 11.0.0&&< 11.1.1 | 11.1.1 |
| 🐘Packagist | typo3/cms-core | ≥ 10.0.0&&< 10.4.14 | 10.4.14 |
| 🐘Packagist | typo3/cms-core | ≥ 11.0.0&&< 11.1.1 | 11.1.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for typo3/cms-form. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2r6j-862c-m2v2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2r6j-862c-m2v2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2r6j-862c-m2v2 in your dependencies?
O3 detects GHSA-2r6j-862c-m2v2 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.