GHSA-5q48-q4fm-g3m6 — v2
Fix: filebrowser/filebrowser#5889GHSA-5q48-q4fm-g3m6 is a Path Traversal vulnerability in github.com/filebrowser/filebrowser/v2. A fix is available for github.com/filebrowser/filebrowser/v2 — see the affected versions and patch details below.
File Browser has an access rule bypass via HasPrefix without trailing separator in path matching
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-5q48-q4fm-g3m6.
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.
Real-World Exposure
github.com/filebrowser/filebrowser/v2Real-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
Hi,
The Matches() function in rules/rules.go uses strings.HasPrefix() without a trailing directory separator when matching paths against access rules. A rule for /uploads also matches /uploads_backup/, granting or denying access to unintended directories. Verified against v2.62.2 (commit 860c19d).
Details
At rules/rules.go:29-35:
func (r *Rule) Matches(path string) bool {
if r.Regex {
return r.Regexp.MatchString(path)
}
return strings.HasPrefix(path, r.Path)
}
When a rule has Path: "/uploads", any path starting with /uploads matches, including /uploads_backup/secret.txt. The regex variant at line 31 uses proper matching, but the non-regex path uses a prefix check without ensuring the match ends at a directory boundary.
The Check() function at http/data.go:29-48 iterates all rules with last-match-wins semantics. No secondary validation exists beyond this prefix check.
PoC
Admin configures: allow rule Path: "/shared" for a restricted user.
Filesystem contains:
/shared/(intended to be accessible)/shared_private/(intended to be restricted)
User requests /shared_private/secret.txt:
strings.HasPrefix("/shared_private/secret.txt", "/shared")returns true- Allow rule applies
- Access granted to the unintended directory
Impact
Authenticated users can access files in sibling directories that share a common prefix with an allowed directory, bypassing the admin's intended access configuration.
Prior art
Prior advisories GHSA-4mh3-h929-w968 (path-based access control bypass) and GHSA-9f3r-2vgw-m8xp (path traversal in copy/rename) addressed related access control issues. This HasPrefix prefix-collision is a distinct, unreported variant.
Suggested Fix
func (r *Rule) Matches(path string) bool {
if r.Regex {
return r.Regexp.MatchString(path)
}
prefix := r.Path
if prefix != "/" && !strings.HasSuffix(prefix, "/") {
prefix += "/"
}
return path == r.Path || strings.HasPrefix(path, prefix)
}
Koda Reef
Update: Fix submitted as PR #5889.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/filebrowser/filebrowser/v2 | all versions | 2.63.1go get github.com/filebrowser/filebrowser/v2@v2.63.1 |
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/filebrowser/filebrowser/v2 to 2.63.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5q48-q4fm-g3m6 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-5q48-q4fm-g3m6 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-5q48-q4fm-g3m6. 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-5q48-q4fm-g3m6 in your dependencies?
O3 Security finds GHSA-5q48-q4fm-g3m6 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.