TYPO3 CMS vulnerable to Denial of Service in Page Error Handling
Published 13 Dec 2022 · Updated 6 Dec 2023
Affected packages
- Affected
- >=9.0.0 <9.5.38
- Fixed in
- 9.5.38
composer require typo3/cms-core:^9.5.38- Affected
- >=10.0.0 <10.4.33
- Fixed in
- 10.4.33
composer require typo3/cms-core:^10.4.33- Affected
- >=11.0.0 <11.5.20
- Fixed in
- 11.5.20
composer require typo3/cms-core:^11.5.20- Affected
- >=10.0.0 <10.4.33
- Fixed in
- 10.4.33
composer require typo3/cms:^10.4.33- Affected
- >=11.0.0 <11.5.20
- Fixed in
- 11.5.20
composer require typo3/cms:^11.5.20Details
Problem
Requesting invalid or non-existing resources via HTTP triggers the page error handler, which again could retrieve content to be shown as an error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.
This vulnerability is very similar, but not identical, to the one described in TYPO3-CORE-SA-2021-005 (CVE-2021-21359).
Solution
Update to TYPO3 versions 9.5.38 ELTS, 10.4.33 or 11.5.20 that fix the problem described above.
References
Is GHSA-8c28-5mp7-v24h in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected typo3/cms-core, and gives you the command that fixes it.
References
- Linkgithub.com/TYPO3/typo3/security/advisories/GHSA-8c28-5mp7-v24h
- Advisorynvd.nist.gov/vuln/detail/CVE-2022-23500
- Linkgithub.com/TYPO3/typo3/commit/1e5f44417f031c9c5a9f9d09a6a841cf89aa7b7a
- Linkgithub.com/TYPO3/typo3/commit/73b46b6a627093112cfca4b895a198ca5e1970b7
- Linkgithub.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/CVE-2022-23500.yaml
- Packagegithub.com/TYPO3/typo3
- Linktypo3.org/security/advisory/typo3-core-sa-2022-012
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.