GHSA-mmpx-jh39-wrv6 is a medium-severity (CVSS 5.4) vulnerability in github.com/gtsteffaniak/filebrowser. A fix is available for github.com/gtsteffaniak/filebrowser — see the affected versions and patch details below.
FileBrowser Vulnerable to Stored XSS via SVG File in Public Share (Missing CSP Header)
Real-World Exposure
github.com/gtsteffaniak/filebrowserReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
FileBrowser Quantum serves inline SVG files without a Content-Security-Policy header, allowing embedded JavaScript in SVG files to execute when accessed via public share links.
Verified on v1.3.0-stable.
Affected product
- Product: FileBrowser Quantum (
gtsteffaniak/filebrowser) - Verified version: v1.3.0-stable
- Docker image: gtstef/filebrowser:latest
- Affected endpoint:
GET /public/api/resources/download?hash=HASH&inline=true - CWE: CWE-79 — Cross-site Scripting (Stored)
Impact
- Stored XSS — Malicious SVG persists and executes for every visitor to the share link
- No authentication required to trigger — Public share links are accessible to anyone
- Session hijacking — If authenticated users click the link, their session can be stolen
- Phishing — Attacker can redirect or overlay fake login forms
Reproduction
- Login as any user with upload permission
- Upload SVG file:
<svg xmlns="http://www.w3.org/2000/svg"> <script>alert(document.domain)</script> </svg> - Create public share for the file
- Access the share link with
?inline=true - JavaScript executes in browser
Root cause
The inline download endpoint returns SVG files with:
Content-Type: image/svg+xml
Content-Disposition: inline; filename="xss.svg"
X-Content-Type-Options: nosniff
But no CSP header to block script execution. The upstream project (filebrowser/filebrowser) mitigates this with:
Content-Security-Policy: script-src 'none'
Suggested fix
Add CSP header on inline file downloads:
w.Header().Set("Content-Security-Policy", "script-src 'none'")
This matches the upstream filebrowser/filebrowser implementation.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gtsteffaniak/filebrowser | all versions | 0.0.0-20260501184955-6bfc3974192ego get github.com/gtsteffaniak/filebrowser@v0.0.0-20260501184955-6bfc3974192e |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gtsteffaniak/filebrowser, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/gtsteffaniak/filebrowser to 0.0.0-20260501184955-6bfc3974192e or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mmpx-jh39-wrv6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-mmpx-jh39-wrv6 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-mmpx-jh39-wrv6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mmpx-jh39-wrv6 in your dependencies?
O3 Security finds GHSA-mmpx-jh39-wrv6 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.