CVE-2026-72837: 
Wolfi vulnerability analysis and mitigation

CVE-2026-72837 is an improper access control vulnerability in File Browser (filebrowser/filebrowser) that allows authenticated users to bypass directory isolation and access the server root scope. Versions before 2.63.20 are affected; version 2.63.20 is the patched release. The vulnerability was published on August 14, 2026, and was independently reported by researchers @thesmartshadow and @B1gN0Se. It carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, GitHub Advisory DB).

The root cause is classified as CWE-284 (Improper Access Control) and CWE-863 (Incorrect Authorization). When createUserDir=true is configured, the MakeUserDir function in settings/dir.go only derives a per-user home directory when the incoming scope is an empty string; however, the proxy auth path (auth/proxy.go) and hook auth path (auth/hook.go) both pass the default scope value "." rather than an empty string, which MakeUserDir normalizes to / (the server root). As a result, every auto-provisioned proxy-auth or hook-auth user is saved with Scope="/" instead of an isolated per-user directory like /users/alice. The regular signup handler (http/auth.go) correctly clears the scope before calling MakeUserDir, so JSON-based /api/signup is not affected. Exploitation requires auth.method=proxy (or hook auth), createUserDir=true, and defaults.scope=. (the CLI default), and only a valid low-privileged upstream identity — no admin privileges or reverse-proxy bypass are needed (GitHub Advisory).

Any authenticated user provisioned via proxy or hook authentication can read, create, overwrite, rename, share, and delete files belonging to all other users within the File Browser server root. This effectively eliminates the directory isolation that createUserDir is intended to enforce, exposing all data stored under the configured File Browser root — including files of other users and potentially administrative or application files. The confidentiality, integrity, and availability of all user data within the server root are fully compromised for any affected deployment (GitHub Advisory, GitHub Advisory DB).

A proof-of-concept (PoC) has been documented in the official security advisory, demonstrating exploitation both behind a real Nginx reverse proxy and directly on loopback using the trusted proxy header. CISA's SSVC assessment classifies exploitation status as "poc" with technical impact rated "total." The EPSS score is approximately 0.3% (23rd percentile), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the disclosure date (GitHub Advisory, GitHub Advisory DB).

1. Identify a vulnerable deployment: Locate a File Browser instance (versions ≤ 2.63.19) configured with auth.method=proxy or hook authentication, createUserDir=true, and defaults.scope=..
2. Obtain valid upstream credentials: Acquire any legitimate account recognized by the upstream authentication provider (e.g., a basic auth account on the reverse proxy). No File Browser admin privileges are required.
3. Trigger auto-provisioning: Authenticate to the File Browser API endpoint (e.g., POST /api/login) with the X-Remote-User header set to your username. This causes File Browser to auto-provision your account with Scope="/" (server root) instead of an isolated directory.
4. Verify scope assignment: Confirm that your provisioned account has Scope="/" by inspecting the user list or attempting to browse the root directory.
5. Access other users' files: Use your session token to read, overwrite, rename, delete, or share files belonging to other users stored anywhere under the File Browser server root via the standard File Browser API or UI.
   • Example: curl -H 'Authorization: Bearer <attacker_token>' http://<host>/api/resources/victim-file.txt to read a victim's file.
   • Example: curl -X DELETE -H 'Authorization: Bearer <attacker_token>' http://<host>/api/resources/victim-file.txt to delete it.
6. Create public shares: Optionally, create public share links for other users' data to exfiltrate or expose it externally (GitHub Advisory).

• Logs: File Browser access logs showing multiple distinct usernames (auto-provisioned via proxy/hook auth) all accessing files outside their expected /users/<username>/ directories; API requests to /api/resources/ paths belonging to other users from a single session token.
• File System: Absence of per-user subdirectories under the configured UserHomeBasePath (e.g., no /users/alice/ or /users/bob/ directories created despite createUserDir=true); files stored directly under the File Browser server root rather than in user-specific subdirectories.
• User Configuration: Presence of auto-provisioned users with Scope="/" in the File Browser user database (detectable via filebrowser users ls or the admin API), particularly users created via proxy or hook authentication.
• Network: Unexpected cross-user file access patterns in HTTP logs — e.g., user A's session token accessing paths associated with user B; unusual DELETE, PUT, or POST requests to /api/resources/ for files not owned by the authenticated user.
• Sharing Activity: Unexpected public share links created for files belonging to users other than the share creator (GitHub Advisory).

Upgrade File Browser to version 2.63.20 or later, which centralizes auto-provisioned user creation in settings.CreateUserHome so that proxy auth, hook auth, and signup paths cannot diverge in scope assignment. As a temporary workaround if immediate patching is not possible, do not rely on createUserDir for isolation under proxy or hook auth — instead, assign each provisioned user an explicit, non-overlapping scope. Administrators should also audit all externally-provisioned users for Scope="/" and relocate them into per-user directories, and restrict network access to the File Browser instance to trusted users only (GitHub Advisory).

The vulnerability was independently reported by two researchers, @thesmartshadow (proxy auth) and @B1gN0Se (proxy and hook auth), and the advisory consolidates both reports. Coverage appeared on The Hacker Wire and was tracked by VulnCheck, which served as the CVE assigning authority. No significant broader media coverage or notable community debate has been identified beyond standard vulnerability tracking and aggregation sites (GitHub Advisory).