File Browser: Authentication Bypass via Proxy Auth Header Forgery
Summary
When FileBrowser is configured with proxy authentication (auth.method=proxy), any unauthenticated attacker who can reach the server directly can impersonate any user - including admin - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to automatically create a new user account, providing an account creation primitive with no authorization.
This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before.
Severity
HIGH - CVSS 3.1: 8.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
Affected Component
- File: [
auth/proxy.go](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28 - CWE: [CWE-287](https://cwe.mitre.org/data/definitions/287.html) (Improper Authentication), [CWE-290](https://cwe.mitre.org/data/definitions/290.html) (Authentication Bypass by Spoofing)
- Affected versions: All versions supporting
auth.method=proxy
Prerequisite: Proxy Auth Must Be Enabled
This vulnerability is NOT exploitable on default configuration (auth.method=json). It requires the administrator to have configured proxy authentication mode. However, this is a common production deployment pattern - many organizations run FileBrowser behind a reverse proxy that handles SSO/LDAP/OAuth authentication:
- nginx + Authelia / Authentik
- Traefik + OAuth2 Proxy
- Caddy + forward_auth
- Apache + mod_auth_ldap
In these setups, the proxy authenticates the user and passes the username via HTTP header (e.g., X-Remote-User). FileBrowser trusts this header to identify the user.
| Deployment Scenario | Exploitable? |
|---|---|
| Default install (auth.method=json) | No — JSON auth uses password verification |
| auth.method=proxy + FileBrowser only reachable via proxy (bound to 127.0.0.1 or firewalled) | No - attacker cannot reach the server directly |
| auth.method=proxy + FileBrowser port exposed to network | Yes - full admin takeover |
The third scenario is common because:
- Docker containers publish ports to
0.0.0.0 by default (e.g., -p 8085:80) - Administrators expose the port for debugging, monitoring, or health checks
- Cloud deployments may have misconfigured security groups or load balancers
- Internal networks often lack strict micro-segmentation
The core issue is that the code itself has zero defensive checks — no trusted IP validation, no shared secret, no origin verification. The entire security model relies on network-level isolation, which is fragile and not documented as a hard requirement.
Root Cause
The ProxyAuth.Auth() function unconditionally trusts the value of an HTTP request header (configured via auth.header, e.g. X-Remote-User) to determine the authenticated user's identity. There are three distinct problems in this code:
Problem 1: No Origin Validation
The function reads the header from any HTTP request regardless of source IP. It does not verify that the request originated from a trusted reverse proxy. Any client on the network can set arbitrary HTTP headers.
File: [auth/proxy.go](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28:
```go
func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {
username := r.Header.Get(a.Header) // <-- reads attacker-controlled header, no origin check
user, err := usr.Get(srv.Root, username)
if errors.Is(err, fberrors.ErrNotExist) {
return a.createUser(usr, setting, srv, username)
}
return user, err // <-- returns the user object, no password verification
}
```
There is no call to verify r.RemoteAddr against a list of trusted proxy IPs, no shared secret validation, and no signature check on the header value.
Problem 2: No Password Verification
Unlike JSON auth (auth/json.go) which validates the password via bcrypt, the proxy auth path returns the user object directly from the database based solely on the header value. The loginHandler in http/auth.go then mints a valid JWT for this user:
File: [http/auth.go](https://github.com/filebrowser/filebrowser/blob/main/http/auth.go), lines 121-137:
```go
func loginHandler(tokenExpireTime time.Duration) handleFunc {
return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) {
auther, err := d.store.Auth.Get(d.settings.AuthMethod)
// ...
user, err := auther.Auth(r, d.store.Users, d.settings, d.server)
// No additional verification — if auther.Auth() returns a user, a JWT is minted
return printToken(w, r, d, user, tokenExpireTime) // <-- signs and returns JWT
}
}
```
Problem 3: Automatic User Creation
If the username in
