GHSA-jq6g-4v5m-wm9r
Information Disclosure due to Out-of-scope Site Resolution
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Packagist | typo3/cms-core | >= 9.4.0, < 9.5.42 | 9.5.42 |
| Packagist | typo3/cms-core | >= 10.0.0, < 10.4.39 | 10.4.39 |
| Packagist | typo3/cms-core | >= 11.0.0, < 11.5.30 | 11.5.30 |
| Packagist | typo3/cms-core | >= 12.0.0, < 12.4.4 | 12.4.4 |
Details
As written in the advisory (Markdown source, shown as plain text).
> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)
### Problem
In multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.
### Solution
Update to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.
> ℹ️ **Strong security defaults - Manual actions required**
> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.
> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.
### Credits
Thanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the issue.
### References
* [TYPO3-CORE-SA-2023-003](https://typo3.org/security/advisory/typo3-core-sa-2023-003)
References
External links from the advisory. They lead to third-party sites.