GHSA-g4xv-r3qw-v3q2
typo3 Information Disclosure Security Note
Blast Radius
typo3/neos🐘typo3/neos🐘typo3/neos🐘typo3/neos🐘typo3/neos🐘typo3/neos🐘typo3/neos🐘typo3/neos+1 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
Due to reports it has been validated that internal workspaces in Neos are accessible without authentication. Some users assumed this is a planned feature but it is not. A workspace preview should be an additional feature with respective security measures in place.
Note that this only allows reading of internal workspaces not writing. And for clarification, an internal workspace is a workspace that is non public and doesn't have an owner.
Given that an internal workspace exists in your installation, it is possible to view a page in context of that workspace by opening a link in this format:
https://domain/path/to/page.html@workspace-name
The issue is quite problematic when exploited but at the same time slightly less impactful than it sounds. First of all there is no default internal workspace, so the issue affects only workspaces created by users. That also means the workspace-name, which will also always include a hash is individual to a project and an exploiter must get hold of the workspace-name including the hash. This is non trivial as there is no indication of the existence of it, but obviously brute force and educated guessed can be made.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | typo3/neos | ≥ 2.3.0&&< 2.3.99 | 2.3.99 |
| 🐘Packagist | typo3/neos | ≥ 3.0.0&&< 3.0.20 | 3.0.20 |
| 🐘Packagist | typo3/neos | ≥ 3.1.0&&< 3.1.18 | 3.1.18 |
| 🐘Packagist | typo3/neos | ≥ 3.2.0&&< 3.2.14 | 3.2.14 |
| 🐘Packagist | typo3/neos | ≥ 3.3.0&&< 3.3.23 | 3.3.23 |
| 🐘Packagist | typo3/neos | ≥ 4.0.0&&< 4.0.17 | 4.0.17 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for typo3/neos. 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/neos to 2.3.99 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g4xv-r3qw-v3q2 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-g4xv-r3qw-v3q2 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-g4xv-r3qw-v3q2. 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-g4xv-r3qw-v3q2 in your dependencies?
O3 detects GHSA-g4xv-r3qw-v3q2 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.