File Browser has a Command Execution Allowlist Bypass via Shell Metacharacter Injection
Description
Shell metacharacter injection in filebrowser's command execution allowlist allows arbitrary command execution when a shell interpreter is configured.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Shell metacharacter injection in filebrowser's command execution allowlist allows arbitrary command execution when a shell interpreter is configured.
Vulnerability
In filebrowser, when a shell interpreter is configured (e.g., /bin/sh -c), the command allowlist can be bypassed through shell metacharacters. The ParseCommand function in runner/parser.go extracts only the first token via SplitCommandAndArgs for the allowlist check, but then passes the entire raw user input to the shell. The commandsHandler in http/commands.go uses slices.Contains to verify the first token against the allowlist, but the shell interprets the full string, including metacharacters like ;, |, ` `, and $(). This vulnerability affects all filebrowser versions where the command execution feature is enabled and a shell interpreter is set. The feature has been disabled by default from v2.33.8 onwards, but administrators can re-enable it via the --disable-exec=false flag or FB_DISABLE_EXEC=false` environment variable [1][2][3].
Exploitation
An attacker must have a valid user account with permission to run commands on a filebrowser instance where the administrator has enabled the command execution feature (and ignored the associated security warnings). The attacker then submits a command string that starts with an allowed command (e.g., ls) followed by shell metacharacters and arbitrary commands (e.g., ls; id; cat /etc/shadow). The allowlist check passes because the first token (ls) is permitted, but the shell executes the entire string, chaining the attacker's commands [1][2].
Impact
Successful exploitation results in arbitrary command execution with the privileges of the filebrowser process. This can lead to full system compromise, including data exfiltration, installation of malware, or lateral movement within the network. The impact is limited only by the permissions of the filebrowser process and the underlying operating system [1][2].
Mitigation
No code-level patch has been released for this vulnerability. The filebrowser project has disabled the command execution feature by default from v2.33.8 onwards and strongly recommends against re-enabling it. Administrators should ensure the feature remains disabled (the default setting) and avoid using the --disable-exec=false flag or FB_DISABLE_EXEC=false environment variable. For instances that must use the feature, the project advises accepting the known security risks and monitoring for unusual activity [1][2][3].
AI Insight generated on Jun 12, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1- Range: < 2.33.8
Patches
1b0f92dd2d72achore(release): 2.33.8
1 file changed · +2 −0
CHANGELOG.md+2 −0 modified@@ -2,6 +2,8 @@ All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines. +### [2.33.8](https://github.com/filebrowser/filebrowser/compare/v2.33.7...v2.33.8) (2025-06-25) + ### [2.33.7](https://github.com/filebrowser/filebrowser/compare/v2.33.6...v2.33.7) (2025-06-25)
Vulnerability mechanics
Root cause
"ParseCommand checks only the first token against the allowlist but passes the entire raw input (including shell metacharacters) to the shell interpreter."
Attack vector
An attacker must be a user with Execute permission and the instance must have command execution enabled with a shell interpreter configured (e.g., `/bin/sh -c`) and an allowlist active. The attacker logs in, obtains a JWT, opens a WebSocket to `/api/command/`, and sends an input whose first token is an allowed command (e.g. `ls`) followed by shell metacharacters like `;`, `|`, or backticks to chain arbitrary commands. The allowlist permits the first token but the whole string is passed to the shell, so `ls; id; cat /etc/passwd` executes all three commands [ref_id=1][ref_id=2].
Affected code
`runner/parser.go`, function `ParseCommand` (lines 10–25) extracts the first token via `SplitCommandAndArgs` for the allowlist check but passes the full raw input to the shell when a shell interpreter is configured. `http/commands.go`, function `commandsHandler` (lines 72–86) uses the token `name` for allowlist validation yet the constructed command executes the uncontrolled raw string via `/bin/sh -c` [ref_id=1][ref_id=2].
What the fix does
The commit corresponding to release v2.33.8 [patch_id=5753231] only updates the changelog for the new release; the vulnerability was addressed by **disabling the Command Execution feature by default** for all installations from v2.33.8 onward [ref_id=1][ref_id=2]. Administrators must explicitly opt in and acknowledge warnings before the feature becomes active. No code-level fix is shown — the mitigation is a default-off toggle rather than patching the parsing logic.
Preconditions
- configCommand Execution feature must be explicitly enabled (the feature is disabled by default from v2.33.8 onward)
- configShell interpreter configured to `/bin/sh -c` or similar
- authUser must have Execute permission and at least one command in the allowlist
- authAttacker must authenticate and obtain a valid JWT
- networkWebSocket connection to `/api/command/` with the JWT in the `X-Auth` header
Generated on Jun 12, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.