Sulu: Fix authorization bypass when creating preview linksGHSA-65cv-w493-7vhq
Fix: sulu/sulu@44d8844GHSA-65cv-w493-7vhq is a CWE-862 vulnerability in sulu/sulu. A fix is available for sulu/sulu — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- 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-65cv-w493-7vhq.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
sulu/sulu🐘sulu/suluReal-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
Impact
A missing authorization check on the preview link endpoint lets a backend user create a public, unauthenticated preview URL for content they are not allowed to see.
PreviewLinkController (and the underlying PreviewLinkManager::generate() / revoke()) never enforced a permission on the target resource. Any authenticated administration user could call the generate action for any page, article or snippet, including content in a webspace or area they have no VIEW rights on. The endpoint returns a public render URL that resolves the content solely by an opaque token, so the attacker (or anyone they share the link with) can then read the restricted content without authentication.
This affects installations that use Sulu role and webspace permissions to restrict who may see certain content. Exploitation requires an authenticated backend user and the id of the target resource.
Patches
Fixed in 2.6.x and 3.0.x. PreviewLinkManager::generate() and revoke() now resolve the resource's security context and enforce a VIEW permission check before a preview link is created or removed. A user without VIEW access on the resource receives a 403 response and no link is created.
Note on scope: this patch closes the authorization bypass. Two related hardening items from the original report are tracked as a separate follow-up because they require a database migration:
- The preview link token is derived from
substr(md5(uuid), 0, 12)(about 48 bits of entropy). - Preview links never expire.
Workarounds
If you cannot upgrade immediately:
- Restrict backend access so that only trusted users can reach the administration interface.
- Apply the fix manually by adding a VIEW permission check (via
SecurityCheckerInterfaceand the resource's security context) insidePreviewLinkManager::generate()andrevoke().
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | sulu/sulu | all versions | 2.6.25composer require sulu/sulu:^2.6.25 |
| 🐘Packagist | sulu/sulu | ≥ 3.0.0-alpha1&&< 3.0.8 | 3.0.8composer require sulu/sulu:^3.0.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sulu/sulu, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update sulu/sulu to 2.6.25 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-65cv-w493-7vhq is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-65cv-w493-7vhq in your dependencies?
Find it across Packagist, including transitive dependencies.