[!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:

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: beforeupload, afterupload, beforerename, afterrename, beforedelete, afterdelete, etc.

Attack Scenario / Reproduction Steps

1. Admin configures an afterupload 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 TestPoCFileHookInjection(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{ "afterupload": {"echo Uploaded $FILE"}, }, }, }

// Malicious filename crafted by the attacker maliciousFilename := "/tmp/safe; id #"

// Simulate the exec logic in runner/runner.go raw := r.Commands["afterupload"][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) }

Summary When a user creates a public share link for a directory, the withHashFile middleware in http/public.go (line 59) uses filepath.Dir(link.Path) to compute the BasePathFs root. This sets the filesystem root to the parent directory instead of the shared directory itself, allowing anyone with the share link to browse and download files from all sibling directories.

Details In http/public.go lines 52-64, the withHashFile function handles public share link requests:

go basePath := link.Path // e.g. "/documents/shared" filePath := ""

if file.IsDir { basePath = filepath.Dir(basePath) // BUG: becomes "/documents" (parent!) filePath = ifPath }

d.user.Fs = afero.NewBasePathFs(d.user.Fs, basePath)

When a directory at /documents/shared is shared, filepath.Dir("/documents/shared") evaluates to "/documents". The BasePathFs is then rooted at the parent directory /documents/, giving the share link access to everything under /documents/ - not just the intended /documents/shared/.

This affects both publicShareHandler (directory listing via /api/public/share/{hash}) and publicDlHandler (file download via /api/public/dl/{hash}/path).

PoC

1. Set up filebrowser with a user whose scope contains: 2. - /documents/shared/public-file.txt (intended to be shared) 3. - /documents/secrets/passwords.txt (NOT intended to be shared) 4. - /documents/private/financial.csv (NOT intended to be shared) 2. Create a public share link for the directory /documents/shared (via POST /api/share/documents/shared) 3. Access the share link: GET /api/public/share/{hash} 4. - Expected: Lists only contents of /documents/shared/ 5. - Actual: Lists contents of /documents/ (parent), revealing secrets/, private/, and shared/ directories 4. Download sibling files: GET /api/public/dl/{hash}/secrets/passwords.txt 5. - Expected: 404 or 403 (file outside share scope) 6. - Actual: 200 with file contents (sibling file downloaded successfully) Standalone Go test reproducing the exact vulnerable code path with afero.NewBasePathFs:

go func TestShareScopeEscape(t testing.T) { baseFs := afero.NewMemMapFs() afero.WriteFile(baseFs, "/documents/shared/public.txt", []byte("public"), 0644) afero.WriteFile(baseFs, "/documents/secrets/passwords.txt", []byte("admin:hunter2"), 0644)

linkPath := "/documents/shared" basePath := filepath.Dir(linkPath) // BUG: "/documents" scopedFs := afero.NewBasePathFs(baseFs, basePath)

// Sibling file is accessible through the share: f, err := scopedFs.Open("/secrets/passwords.txt") // err is nil - file accessible! Content: "admin:hunter2" }

This test passes, confirming the vulnerability.

Impact

Unauthenticated information disclosure (CWE-200, CWE-706). Anyone with a public share link for a directory can: - Browse all sibling directories and files of the shared directory - - Download any file within the parent directory scope - - This works without authentication (public shares) or after providing the share password (password-protected shares) All filebrowser v2.x installations that use directory sharing are affected.

Recommended Fix

Remove the filepath.Dir() call and use link.Path directly as the BasePathFs root:

go if file.IsDir { // Don't change basePath - keep it as link.Path filePath = ifPath } d.user.Fs = afero.NewBasePathFs(d.user.Fs, basePath)

Affected commit: e3d00d591b567a8bfe3b02e42ba586859002c77d (latest) File: http/public.go, line 59