GHSA-5q48-q4fm-g3m6
GHSA-5q48-q4fm-g3m6 is a Path Traversal vulnerability in github.com/filebrowser/filebrowser/v2. O3 Security confirms whether GHSA-5q48-q4fm-g3m6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
File Browser has an access rule bypass via HasPrefix without trailing separator in path matching
Blast Radius
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.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. 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.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 pinpoints whether GHSA-5q48-q4fm-g3m6 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-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 detects GHSA-5q48-q4fm-g3m6 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.