Signup can grant unauthenticated shell execution in File Browser

TL;DR — A misapplied default-permissions flow can let public self-signup users inherit server-side command execution rights, turning an exposed File Browser instance into a remote shell under the app’s OS privileges.

What happened

File Browser is a self-hosted web UI for managing files (upload, rename, preview, edit) inside a configured server-side directory.

CVE-2026-34528 (CVSS v3.1 8.1 High) describes a privilege/permission inheritance flaw where the signupHandler applies a default user template and only strips the Admin flag, leaving Execute and the Commands allowlist intact. In deployments where an administrator has enabled public signup, enabled server-side command execution, and configured the default user template with Execute=true and one or more commands, an unauthenticated attacker can self-register and then invoke those commands (e.g., via /api/command/) to achieve arbitrary shell execution in the context of the File Browser process.

This issue is particularly high-signal for platform teams because “public signup + powerful admin-configured defaults” is a common pattern in self-hosted internal tools; a single defaults mistake can quietly convert an internet-exposed service into an RCE surface.

Who is impacted

• Deployments running github.com/filebrowser/filebrowser/v2 versions prior to 2.62.2.
• Highest risk where all of the following are true:
  • Public self-registration is enabled (signup).
  • Server-side command execution is enabled (enableExec).
  • Default user template includes Execute=true and a populated Commands list.

What to do now

• Follow vendor remediation guidance and apply the patched release identified in the advisory/CVE record.
  • The CVE record states: this issue "has been patched in version 2.62.2".
• If you cannot patch immediately, reduce exposure by removing one or more prerequisite conditions in your deployment:
  • Disable public signup where not strictly required.
  • Disable server-side execution (enableExec) where not strictly required.
  • Ensure the default user template does not grant Execute and does not include a Commands allowlist for self-registered users.
• Treat suspicious signup + command activity as a potential compromise signal:
  • Review application and reverse-proxy logs for unexpected requests to POST /api/signup, subsequent POST /api/login, and WebSocket connections to /api/command/.
  • Rotate secrets reachable by the File Browser process (environment variables, adjacent service credentials, tokens on disk) if the instance was exposed with execution enabled.