GHSA-pp4x-ccxq-6r33: XSS
Impact
Stored Cross Site Scripting (XSS) in the media download endpoint.
The download route (/media/{id}/download/{slug} and its admin variant) accepts the query parameter ?inline=1. When it is present, the response is sent with the header Content-Disposition: inline for any MIME type, which overrides the disposition rules the server would otherwise apply. By default, HTML and other scriptable uploads are not blocked, the file is served on the application origin with its stored Content-Type, and no X-Content-Type-Options or Content-Security-Policy header is sent. Because of this, an attacker can upload an HTML file and build a link that runs their own JavaScript in the context of the Sulu origin.
Every installation where users who are not fully trusted can upload media is affected. This includes editors who hold the media add permission. Such an editor can store a payload that runs in the authenticated session of anyone who opens the link, including an administrator, which allows theft of the session and credentials and lets the attacker act as the victim.
The problem is present on the 2.6 and 3.0 branches and goes back to the introduction of the ?inline override in 2017. It is not the same as CVE-2024-47617, which was a reflected XSS through the slug and is already fixed.
Patches
Fixed in 2.6.25 and 3.0.8. The download route now forces Content-Disposition: attachment for MIME types a browser renders as a document (text/html, application/xhtml+xml, text/xml, application/xml), even when ?inline=1 is requested. Inline viewing is unchanged for safe types such as PDF and images.
Workarounds
Block scriptable uploads by MIME type through sulumedia.upload.blockedfiletypes. This stops new uploads only, so existing media has to be reviewed separately.
yaml sulumedia: upload: blockedfiletypes: [text/html, application/xhtml+xml, image/svg+xml, text/xml, application/xml, text/javascript, application/javascript]
At the web server or reverse proxy, force Content-Disposition: attachment and add X-Content-Type-Options: nosniff and a restrictive Content-Security-Policy on the paths /media//download/ and /admin/media//download/.
Serve uploaded media from a separate origin that does not share the application cookies.
Restrict the media upload permission to trusted users and keep the default SVG sanitizer enabled.
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.25 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.8 - Configuration
Block scriptable uploads by adding the listed MIME types to sulu_media.upload.blocked_file_types (default HTML and other scriptable types are not blocked).
Sulu media upload sulu_media.upload.blocked_file_types = [text/html, application/xhtml+xml, image/svg+xml, text/xml, application/xml, text/javascript, application/javascript] - Configuration
For paths /media/*/download/* and /admin/media/*/download/*, force Content-Disposition: attachment to prevent inline execution.
Web server / reverse proxy Content-Disposition = attachment - Configuration
For paths /media/*/download/* and /admin/media/*/download/*, add X-Content-Type-Options: nosniff to prevent MIME sniffing.
Web server / reverse proxy X-Content-Type-Options = nosniff - Configuration
For paths /media/*/download/* and /admin/media/*/download/*, add a restrictive Content-Security-Policy header as a workaround.
Web server / reverse proxy Content-Security-Policy = restrictive (not further specified) - Compensating control
Restrict the media upload permission to trusted users and keep the default SVG sanitizer enabled.
- Compensating control
Serve uploaded media from a separate origin that does not share the application cookies.
- Operational
Review existing uploaded media separately, because the workaround/fix stops new uploads only and previously stored payloads may still be accessible.
Event History
Frequently Asked Questions
Which deployments are exposed?
Every installation in which users who are not fully trusted can upload media is affected. This includes editors with the media add permission, because HTML and other scriptable uploads are not blocked by default.
What does an attacker need to exploit this issue?
The attacker needs permission to upload media and must persuade an authenticated victim to open a crafted media download link containing ?inline=1. The uploaded HTML then runs JavaScript under the Sulu origin in the victim's authenticated session.
What is the likely impact if an administrator opens a malicious link?
The attacker can steal the victim's session and credentials and act as that victim. An administrator who opens the link can therefore expose administrative access.
Are default response protections sufficient to prevent exploitation?
No. Scriptable files are not blocked by default, are served from the application origin with their stored Content-Type, and responses do not include X-Content-Type-Options or Content-Security-Policy headers.