GitHub Security Advisory: GHSA-jvpw-637p-h3pw
Package: github.com/filebrowser/filebrowser/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: >= 2.0.0-rc.1, <= 2.63.1
Patched in: unpatched

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`:

```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