GHSA-mmpx-jh39-wrv6 json
FileBrowser Vulnerable to Stored XSS via SVG File in Public Share (Missing CSP Header)
published 6mo ago modified 4mo ago also GO-2026-5511
- cvss
- 5.4
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
## 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
1. Login as any user with upload permission 2. Upload SVG file: ```xml <svg xmlns="http://www.w3.org/2000/svg"> <script>alert(document.domain)</script> </svg> ``` 3. Create public share for the file 4. Access the share link with `?inline=true` 5. 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:
```go w.Header().Set("Content-Security-Policy", "script-src 'none'") ```
This matches the upstream filebrowser/filebrowser implementation.
Patch / fix
- go github.com/gtsteffaniak/filebrowser 0.0.0-20260501184955-6bfc3974192e
Is GHSA-mmpx-jh39-wrv6 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 5.4 | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/gtsteffaniak/filebrowser | <0.0.0-20260501184955-6bfc3974192e |
0.0.0-20260501184955-6bfc3974192e |
Classification
- Weakness
-
- CWE-79 Improper Neutralization of Input During Web Page Generation
References
Sources
- GitHub Advisory GHSA-mmpx-jh39-wrv6
- OSV GO-2026-5511
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.