CVE-2026-54089: Authentication Bypass by Spoofing in File Browser

File Browser is an open-source web-based file management interface designed to provide users with a platform to upload, delete, preview, rename, and edit files within a specified directory. To accommodate various organizational integration patterns, File Browser supports multiple authentication methods, including JSON web tokens, external command execution, and proxy-based authentication. When proxy-based authentication (auth.method=proxy) is configured, File Browser delegates identity verification to an upstream reverse proxy.

Under this architecture, the upstream proxy authenticates the user and forwards the authenticated identity to File Browser via a specified HTTP header, such as X-Forwarded-User or Remote-User. However, File Browser lacks any built-in mechanism to verify the origin or integrity of these incoming HTTP requests. It does not validate that the request originated from a trusted source IP address, nor does it require any cryptographic verification such as a shared HMAC signature.

Consequently, if an attacker can establish direct network connectivity to the File Browser application port, bypassing the reverse proxy entirely, the application will implicitly trust any client-supplied HTTP headers. This structural trust boundary failure allows unauthenticated remote attackers to impersonate arbitrary users, including the system administrator, by injecting the configured authentication header. The primary weakness is classified under CWE-290 (Authentication Bypass by Spoofing) and CWE-287 (Improper Authentication).

The root cause of CVE-2026-54089 lies within the implementation of the ProxyAuth.Auth method inside the auth/proxy.go source file. This method is invoked during the login handling phase when the application authentication method is set to "proxy". The design relies entirely on the presence of a pre-configured HTTP header key to determine user identity and issue access tokens.

When a request reaches the authentication handler, the application extracts the username directly from the HTTP request headers using the r.Header.Get method. The extracted string is then immediately queried against the underlying BoltDB user store using usr.Get. No verification is performed to check whether the request passed through an authorized gateway, meaning any direct TCP connection to the service port can supply this header and successfully authenticate.

Furthermore, the application exhibits an automatic account registration behavior if the supplied username does not exist in the database. When the query returns fberrors.ErrNotExist, the authentication handler catches this error and calls the internal createUser function. This helper generates a random password, hashes it, instantiates a new user object with default non-admin permissions, and persists it to the database before logging the user in. This behavioral path provides an unauthorized account creation primitive to any network-adjacent or remote attacker.

The authentication logic within File Browser illustrates the implementation gap between trust establishment and enforcement. In auth/proxy.go, the Auth function retrieves the configured header without validation:

// Auth authenticates the user via an HTTP header.
func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {
	// Extract username directly from HTTP header without origin check
	username := r.Header.Get(a.Header)
	user, err := usr.Get(srv.Root, srv.FollowExternalSymlinks, username)
	if errors.Is(err, fberrors.ErrNotExist) {
		// Automatically provision new user account if username is unknown
		return a.createUser(usr, setting, srv, username)
	}
	return user, err
}

In the HTTP routing layer located in http/auth.go, the handler loginHandler invokes this method when processing POST requests to /api/login:

func loginHandler(tokenExpireTime time.Duration) handleFunc {
	return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) {
		// ... [Body parsing and limit checks] ...
		auther, err := d.store.Auth.Get(d.settings.AuthMethod)
		if err != nil {
			return http.StatusInternalServerError, err
		}
 
		// Executes the vulnerable Auth method
		user, err := auther.Auth(r, d.store.Users, d.settings, d.server)
		switch {
		case errors.Is(err, os.ErrPermission):
			return http.StatusForbidden, nil
		case err != nil {
			return http.StatusInternalServerError, err
		}
 
		// Generates and returns a signed JWT token for the authenticated user
		return printToken(w, r, d, user, tokenExpireTime)
	}
}

Because there is no architectural fix provided in the codebase—the vulnerability being categorized as a structural design limitation—remediation must be accomplished via deployment configuration rather than a code patch. The lack of checking for source origins or pre-shared keys means the code continues to trust incoming HTTP metadata implicitly. Security relies entirely on the host configuration preventing direct external communication with the bound port.

Exploitation of CVE-2026-54089 requires three conditions: the target File Browser instance must have proxy authentication enabled, the attacker must know or guess the configured proxy header name, and the application port must be exposed directly to the attacker's network segment.

An attacker can construct a simple request to the login endpoint. If the default header X-Forwarded-User is used, the attack sequence is illustrated in the diagram below:

Following the token generation, the attacker copies the JWT from the HTTP response body and presents it in the X-Auth header of subsequent requests. This grants complete administrative control over the filesystem directories exposed by File Browser, enabling arbitrary file upload, download, modification, and deletion. If the attacker targets a non-existent username instead, the database creates a new account, giving the attacker a persistent entry point with default user permissions.

The security impact of CVE-2026-54089 is severe, leading to a complete compromise of confidentiality and integrity for all files managed by the affected application instance. Because the application processes files directly on the host system or within a container environment, an administrative takeover allows attackers to read, write, or destroy sensitive application data, configuration files, and system backups.

Under CVSS v3.1, this vulnerability is rated at 9.1 (Critical), with a vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The attack complexity is low since it requires no specialized tools or prior credentials. There is no user interaction required, and the attack can be executed entirely over the network.

While availability impact is rated as 'None' under the CVSS vector because File Browser itself does not crash or experience a denial of service directly due to the authentication bypass, the integrity impact allows an attacker to delete or encrypt files, which effectively causes a high-severity operational impact. No active, wild exploitation has been cataloged by CISA, and there is currently no public automated exploit tool, keeping the EPSS score low.

Because CVE-2026-54089 is an inherent design behavior of the proxy authentication feature rather than a programming oversight, no code patch is available. Remediation must be achieved through proper network design and server hardening.

The primary mitigation strategy is network isolation. Administrators must ensure that the File Browser process binds only to localhost (127.0.0.1 or ::1) or resides within an isolated private container network. The application must not be exposed directly to any public or untrusted network interfaces.

Additionally, the upstream reverse proxy must be configured to strip any incoming client-supplied authentication headers. For example, in an Nginx deployment, the proxy configuration must explicitly overwrite the header using values populated by the proxy's own authentication mechanisms, such as $remote_user from auth_basic. This ensures that malicious clients cannot inject arbitrary usernames through HTTP header spoofing. If these network security controls cannot be implemented, administrators must disable proxy authentication entirely and revert to standard database-backed form authentication using the command filebrowser config set --auth.method=json.