Attack Chain

1. An unauthenticated attacker identifies a FileBrowser instance configured with auth.method=proxy that is directly reachable (i.e., not exclusively behind a trusted reverse proxy).
2. The attacker crafts an HTTP POST request to the /api/login endpoint, including a forged HTTP header, typically X-Remote-User, set to a target username such as admin.
3. FileBrowser's ProxyAuth.Auth() function receives the request and extracts the username from the X-Remote-User header, implicitly trusting its value without any origin validation (e.g., checking trusted IP addresses) or cryptographic verification.
4. If the specified username exists, FileBrowser retrieves the corresponding user object from its internal user store. If the username does not exist, the createUser() function is automatically invoked, creating a new user account with default permissions and a locked, random password.
5. The loginHandler proceeds to mint a valid JSON Web Token (JWT) for the impersonated or newly created user. This JWT contains the full permissions of the target user, including administrator privileges if admin was specified.
6. The attacker receives this valid JWT and uses it in subsequent HTTP requests by including it in the X-Auth header to interact with privileged endpoints (e.g., /api/settings, /api/users) or access specific user resources (e.g., /api/resources/).
7. The attacker achieves full administrative control over the FileBrowser instance, allowing modification of server settings, enumeration of all user accounts, and unauthorized access to all files and data within the application's scope.

Impact

Successful exploitation of this vulnerability leads to complete compromise of the FileBrowser instance. Attackers gain full administrative control, allowing them to modify server configurations, create, delete, or modify files, and access sensitive data stored within the FileBrowser environment. This also enables the creation of arbitrary user accounts without authorization, potentially leading to further persistence or resource exhaustion. Organizations deploying FileBrowser behind reverse proxies, especially those exposing the application's port directly to an untrusted network (e.g., due to Docker container defaults or misconfigured cloud security groups), are at high risk of data breach and system compromise.

Recommendation

• Restrict direct access: Configure network firewalls or security groups to ensure the FileBrowser application is only accessible by trusted reverse proxies, preventing direct access from untrusted networks.
• Review logging: Deploy the provided Sigma rule to detect POST requests to /api/login containing the X-Remote-User header. Ensure web server logs capture the X-Remote-User HTTP header for effective detection.
• Update configuration: If direct exposure is unavoidable, consider switching auth.method from proxy to json and implementing alternative, more secure authentication mechanisms at the application layer or within a properly secured reverse proxy setup.
• Implement trusted proxy validation: If using auth.method=proxy is essential, implement stringent trusted proxy validation at the network layer or enhance FileBrowser with origin validation checks (e.g., by contributing a patch to verify r.RemoteAddr against a list of trusted IPs).