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 sulu_media.upload.blocked_file_types. This stops new uploads only, so existing media has to be reviewed separately.
sulu_media:
upload:
blocked_file_types: [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.
References
0x3xP01t3r Reporter
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 headerContent-Disposition: inlinefor 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 storedContent-Type, and noX-Content-Type-OptionsorContent-Security-Policyheader 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
?inlineoverride in 2017. It is not the same as CVE-2024-47617, which was a reflected XSS through theslugand is already fixed.Patches
Fixed in 2.6.25 and 3.0.8. The download route now forces
Content-Disposition: attachmentfor MIME types a browser renders as a document (text/html,application/xhtml+xml,text/xml,application/xml), even when?inline=1is requested. Inline viewing is unchanged for safe types such as PDF and images.Workarounds
Block scriptable uploads by MIME type through
sulu_media.upload.blocked_file_types. This stops new uploads only, so existing media has to be reviewed separately.At the web server or reverse proxy, force
Content-Disposition: attachmentand addX-Content-Type-Options: nosniffand a restrictiveContent-Security-Policyon 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.
References