Sulu: Stored XSS via media download inline-disposition override
Published Aug 31, 2026 · Updated Nov 3, 2026
Original summary
Normalized public record · Updated Nov 3, 2026
Sulu: Stored XSS via media download inline-disposition override
Publisher and source text is retained separately from QFinch interpretation.
QFinch assessment
Stored Cross Site Scripting (XSS) in the media download endpoint.
Potential 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.
Evidence: public source recordsAffected products
| Affected package, product or range | Fix status |
|---|---|
| Consult the referenced vendor advisory for affected versions. | Consult source advisory |
Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.
Remediation
Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.
- Confirm the affected product and reachable code path exist in your environment.
- Apply the vendor-supported patch or mitigation from the primary advisory.
- Rescan the exact deployed revision and retain verification evidence.
Evidence coverage
- SSVC priority
- LOW
- Confidence
- Not available
- Aliases
- None reported
Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.
Sources and record history
Record history
Published Aug 31, 2026 · Last refreshed Nov 3, 2026