OS Command Injection In github.com/filebrowser/filebrowser/v2
Description
File Browser has a Command Injection via Hook Runner
[!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 it also applies to Hook Runners and not just to the Shell Commands, since all advisories until now focused only on the shell command execution.
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 // ......
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_upload hook: 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 id command 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" )...
Mitigation
Update Impact
Minimal update. May introduce new vulnerabilities or breaking changes.
Ecosystem | Package | Affected version | Patched versions |
|---|---|---|---|
go | 2.63.2 |
Aliases
References