TYPO3 vulnerable to an Uncontrolled Resource Consumption in the ShowImageControllerGHSA-36g8-62qv-5957
MEDIUMFix: TYPO3/typo3@05c95feGHSA-36g8-62qv-5957 is a medium-severity (CVSS 5.3) Information Exposure vulnerability in typo3/cms-core. A fix is available for typo3/cms-core — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-36g8-62qv-5957.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
typo3/cms-core🐘typo3/cms-core🐘typo3/cms-core🐘typo3/cms-core🐘typo3/cms-coreReal-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
The ShowImageController (eID tx_cms_showpic) lacks a cryptographic HMAC-signature on the frame HTTP query parameter (e.g. /index.php?eID=tx_cms_showpic?file=3&...&frame=12345).
This allows adversaries to instruct the system to produce an arbitrary number of thumbnail images on the server side.
Solution
Update to TYPO3 versions 9.5.48 ELTS, 10.4.45 ELTS, 11.5.37 LTS, 12.4.15 LTS, 13.1.1 that fix the problem described.
ℹ️ Strong security defaults - Manual actions required
The frame HTTP query parameter is now ignored, since it could not be used by core APIs.
The new feature flag security.frontend.allowInsecureFrameOptionInShowImageController – which is disabled per default – can be used to reactivate the previous behavior.
Credits
Thanks to TYPO3 security team member Torben Hansen who reported this issue and to TYPO3 core & security team members Benjamin Mack and Benjamin Franzke who fixed the issue.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | typo3/cms-core | ≥ 9.0.0&&< 9.5.48 | 9.5.48composer require typo3/cms-core:^9.5.48 |
| 🐘Packagist | typo3/cms-core | ≥ 10.0.0&&< 10.4.45 | 10.4.45composer require typo3/cms-core:^10.4.45 |
| 🐘Packagist | typo3/cms-core | ≥ 11.0.0&&< 11.5.37 | 11.5.37composer require typo3/cms-core:^11.5.37 |
| 🐘Packagist | typo3/cms-core | ≥ 12.0.0&&< 12.4.15 | 12.4.15composer require typo3/cms-core:^12.4.15 |
| 🐘Packagist | typo3/cms-core | ≥ 13.0.0&&< 13.1.1 | 13.1.1composer require typo3/cms-core:^13.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-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update typo3/cms-core to 9.5.48 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-36g8-62qv-5957 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is GHSA-36g8-62qv-5957 in your dependencies?
Find it across Packagist, including transitive dependencies.