GHSA-65cv-w493-7vhq: Composer/sulu/sulu vulnerability
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 SecurityCheckerInterface and the resource's security context) inside PreviewLinkManager::generate() and revoke().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/sulu/suluto a version that resolves this vulnerability.Fixed in 3.0.8 - Upgrade
Upgrade
composer/sulu/suluto a version that resolves this vulnerability.Fixed in 2.6.25 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.6.x - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.x - Configuration
Apply the authorization fix by adding a VIEW permission check (via `SecurityCheckerInterface` and the resource's security context) inside `PreviewLinkManager::generate()` and `PreviewLinkManager::revoke()`, and ensure the controller/endpoint uses this enforcement so a preview link is only created or removed when the caller has VIEW access to the target resource.
PreviewLinkManager / PreviewLinkController VIEW permission check on target resource = enforce (before creating/removing preview links) - Compensating control
Restrict backend access so only trusted users can reach the administration interface (where authenticated backend users can call preview link generate actions).
- Compensating control
Because the endpoint can return a public render URL resolved solely by an opaque token, treat any generated preview URLs as effectively public; limit sharing and access to the preview-rendering path/host using network controls so only intended users can reach it.
Event History
Frequently Asked Questions
Which installations are exposed to this issue?
Installations using Sulu role and webspace permissions to limit visibility of pages, articles, or snippets are affected. The issue matters where backend users may have access to the administration interface without VIEW rights on all content.
What does an attacker need to exploit it?
An attacker needs an authenticated backend user account and the ID of the target page, article, or snippet. They can then request generation of a preview link for content outside their authorized webspace or area.
Can the resulting preview URL be accessed without logging in?
Yes. The generated render URL is public and resolves the target content using only its opaque token, so anyone who receives the URL can read the restricted content without authentication.
What behavior should be expected after applying a fix?
Preview-link generation and revocation resolve the target resource security context and require VIEW permission. Users lacking VIEW access receive a 403 response and no preview link is created.