GHSA-w7qc-6grj-w7r8 is a high-severity (CVSS 8) CWE-77 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 vulnerable to command execution allowlist bypass
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.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w7qc-6grj-w7r8.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-w7qc-6grj-w7r8 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
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
The Command Execution feature of Filebrowser only allows the execution of shell command which have been predefined on a user-specific allowlist. The implementation of this allowlist is erroneous, allowing a user to execute additional commands not permitted.
Impact
A user can execute more shell commands than they are authorized for. The concrete impact of this vulnerability depends on the commands configured, and the binaries installed on the server or in the container image. Due to the missing separation of scopes on the OS-level, this could give an attacker access to all files managed the application, including the File Browser database.
Vulnerability Description
For a user to make use of the command execution feature, two things need to happen in advance:
- An administrator needs to grant that account the
Execute commandspermission - The command to be executed needs to be listed in the
Commandsinput field (also done by an administrator)
If a user tries to execute a different command, it gets rejected by the application.
The allowlist verification of a command happens in the function CanExecute in the file users/users.go:
// CanExecute checks if an user can execute a specific command.
func (u *User) CanExecute(command string) bool {
if !u.Perm.Execute {
return false
}
for _, cmd := range u.Commands {
if regexp.MustCompile(cmd).MatchString(command) {
return true
}
}
return false
}
This check employs a regular expression which does not test if the command issued (command) is identical to a configured one (cmd, part of the array u.Commands) but rather only if the issued command contains an allowed one.
This has the consequence, that, e.g., if you are only granted access to the ls command, you will also be allowed to execute lsof and lsusb.
As a prerequisite, an attacker needs an account with the Execute Commands permission and some permitted commands.
Proof of Concept
Grant a user the Execute commands permission and allow them to use only ls in the Commands field.
Afterwards, login as that user, open a command execution window and execute lsof and lsusb.
Recommended Countermeasures
The CanExecute function in the Filebrowser source code should be fixed to only allow exact matches of the command specified instead of doing partial matching.
The correctness of this fix should be extensively tested in the application's automated test suite.
Timeline
2025-03-25Identified the vulnerability in version 2.32.02025-04-11Contacted the project2025-04-18Vulnerability disclosed to the project2025-06-25Uploaded advisories to the project's GitHub repository2025-06-25CVE ID assigned by GitHub2025-06-26Fix released in version 2.33.10
References
Credits
- Mathias Tausig (SBA Research)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/filebrowser/filebrowser/v2 | all versions | 2.33.10go get github.com/filebrowser/filebrowser/v2@v2.33.10 |
| 🐹Go | github.com/filebrowser/filebrowser | all versions | No fix |
Affected Products
filebrowserfilebrowserDetection & 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.33.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w7qc-6grj-w7r8 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is GHSA-w7qc-6grj-w7r8 in your dependencies?
Find it across Go, including transitive dependencies.