GHSA-rmwh-g367-mj4x
MEDIUMFile Browser allows sensitive data to be transferred in URL
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/filebrowser/filebrowser/v2🐹github.com/filebrowser/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
URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The Filebrowser violates this practice, since access tokens are used as GET parameters.
Impact
The JSON Web Token (JWT) which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to.
Description
Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS.
- The browser history
- The access logs on the affected web server
- Proxy servers or reverse proxy servers
- Third-party servers via the HTTP referrer header
In case attackers can access certain logs, they could read the included sensitive data.
Proof of Concept
When a file is downloaded via the web interface, the JWT is part of the URL:
GET /api/raw/testdir/testfile.txt?auth=eyJh[...]_r4EQ HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: http://filebrowser.local:8080/files/testdir/
Cookie: auth=eyJh[...]_r4EQ
Upgrade-Insecure-Requests: 1
Priority: u=0, i
This also happens when a new command session is started:
GET /api/command/?auth=eyJh[...]YW8BA HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: http://filebrowser.local:8080
Sec-WebSocket-Key: oqQMrF7R34D3lAkj1+ZHTw==
Connection: keep-alive, Upgrade
Cookie: auth=eyJh[...]YW8BA
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Recommended Countermeasures
Sensitive data like session tokens or user credentials should be transmitted via HTTP headers or the HTTP body only, never in the URL.
Timeline
2025-03-27Identified the vulnerability in version 2.32.02025-04-11Contacted the project2025-04-29Vulnerability disclosed to the project2025-06-25Uploaded advisories to the project's GitHub repository2025-06-26CVE ID assigned by GitHub2025-06-26Fix released in version 2.33.9
References
Credits
- Mathias Tausig (SBA Research)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/filebrowser/filebrowser/v2 | all versions | 2.33.9 |
| 🐹Go | github.com/filebrowser/filebrowser | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filebrowser/filebrowser/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/filebrowser/filebrowser/v2 to 2.33.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rmwh-g367-mj4x 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 pinpoints whether GHSA-rmwh-g367-mj4x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rmwh-g367-mj4x. 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-rmwh-g367-mj4x in your dependencies?
O3 detects GHSA-rmwh-g367-mj4x across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.