When FileBrowser is configured with proxy authentication, it trusts the HTTP header (e.g., X-Remote-User) set by the proxy to identify the user without verifying the source IP or any shared secret. The ProxyAuth.Auth() function reads the username from the header and returns the corresponding user object without password verification. If the username does not exist, the server automatically creates a new user account. This allows an attacker who can send requests directly to the FileBrowser server to impersonate any user, including admins, or create new accounts without authentication. The vulnerability is not exploitable on default configurations using JSON authentication and requires the server to be exposed directly to the attacker, which is common in some deployment scenarios due to default Docker port publishing or misconfigured network controls.

An attacker can bypass authentication entirely by forging the proxy authentication header, gaining full access as any user, including administrators. This leads to complete compromise of the FileBrowser instance without needing credentials. Furthermore, the attacker can create new user accounts arbitrarily, providing an unauthorized account creation vector. The vulnerability does not affect default configurations without proxy authentication enabled and requires direct network access to the FileBrowser server port.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, ensure that FileBrowser configured with proxy authentication is not directly accessible to untrusted networks. Restrict access to the FileBrowser server to trusted proxies only, for example by binding to localhost or using firewall rules to limit incoming connections. Do not expose the FileBrowser port publicly or to untrusted internal networks without additional network-level protections. Review deployment configurations to ensure that proxy authentication headers cannot be spoofed by unauthorized clients.