CVE-2026-72836: 
Wolfi vulnerability analysis and mitigation

CVE-2026-72836 is an authorization bypass vulnerability in FileBrowser caused by improper handling of case sensitivity during self-registration on case-insensitive filesystems. When the Signup and CreateUserDir features are enabled and FileBrowser's root resides on a case-insensitive filesystem (e.g., Windows/NTFS), two accounts registered with usernames differing only in letter case (e.g., CaseVictim and casevictim) resolve to the same physical home directory, allowing the second registrant to read, overwrite, and delete the first user's files. The vulnerability affects FileBrowser versions before 2.63.19 and was published on August 14, 2026. It carries a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 9.2 (Critical) (GitHub Advisory, Github Advisory DB).

The root cause is classified as CWE-178 (Improper Handling of Case Sensitivity). The signupHandler derives a user's home directory path using MakeUserDir, then checks for scope ownership via GetByScope, which performs an exact case-sensitive string comparison against the database (q.Eq("Scope", scope)). On case-insensitive filesystems like NTFS, /users/CaseVictim and /users/casevictim are treated as distinct database entries but resolve to the same physical directory. The cleanUsername function permits both upper- and lower-case ASCII characters and preserves their case, enabling the collision. Exploitation requires no existing account or victim interaction — only that the attacker can reach the public signup endpoint (GitHub Advisory). This vulnerability is a bypass of the prior remediation for GHSA-7rc3-g7h6-22m7, which introduced the scope-ownership check that itself remained case-sensitive (GitHub Advisory).

Successful exploitation results in full cross-account compromise of a victim's automatically provisioned home directory, including unauthorized read access (confidentiality), file overwrite and tampering (integrity), and file deletion causing denial of access (availability). Both accounts remain independent in the database and UI, so neither user is alerted that storage is shared, making the attack stealthy. The impact is scoped to the victim's home directory within the FileBrowser instance and does not directly enable lateral movement beyond the application, but sensitive files stored by the victim are fully exposed (GitHub Advisory).

CISA's SSVC assessment classifies exploitation status as "poc" (proof-of-concept available), with technical impact rated "total" and automation rated "no" (NVD). The advisory includes a detailed plaintext reproduction sequence demonstrating the full attack via FileBrowser's actual HTTP handlers, effectively serving as a functional PoC (GitHub Advisory). There is no confirmed evidence of in-the-wild exploitation or threat actor attribution at this time. The EPSS score is approximately 0.321%, indicating a low but non-negligible probability of exploitation in the near term (Github Advisory DB). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify internet-facing FileBrowser instances (versions < 2.63.19) running on Windows/NTFS with Signup and CreateUserDir enabled. This can be done via Shodan, Censys, or by probing the /api/signup endpoint for a 200 response.
2. Register victim account: Send a POST request to /api/signup with a chosen username (e.g., CaseVictim) and password. This creates a home directory at /users/CaseVictim on the filesystem.
3. Register attacker account: Send a second POST request to /api/signup with the same username in different case (e.g., casevictim) and a different password. The case-sensitive database check accepts this as a new account, creating a scope entry /users/casevictim that resolves to the same physical NTFS directory.
4. Authenticate as attacker: Log in as casevictim to obtain a valid session token via /api/login.
5. Read victim files: Use GET /api/raw/<filename> with the attacker's session to read files uploaded by CaseVictim from the shared physical directory.
6. Overwrite victim files: Use POST /api/resources/<filename>?override=true with attacker credentials to replace the victim's files with attacker-controlled content.
7. Delete victim files: Use DELETE /api/resources/<filename> with attacker credentials to permanently remove the victim's files, causing HTTP 404 for the victim on subsequent access (GitHub Advisory).

• Network: Two or more POST requests to /api/signup from the same or different IP addresses within a short timeframe, where usernames differ only in letter case; unexpected GET/POST/DELETE requests to /api/raw/, /api/resources/, or /api/rawpreview/ from a session belonging to a recently registered account accessing files not created by that account.
• Logs: FileBrowser access logs showing successful HTTP 200 responses for two signup requests with case-variant usernames (e.g., CaseVictim and casevictim); HTTP 200 responses to GET /api/raw/<file> for a user who did not upload the requested file; HTTP 204 responses to DELETE /api/resources/<file> followed by HTTP 404 for the same resource from a different account.
• File System: Two database entries with scopes differing only in case (e.g., /users/CaseVictim and /users/casevictim) that os.SameFile() confirms point to the same physical directory on NTFS; unexpected modification or deletion timestamps on files in a user's home directory not matching that user's activity (GitHub Advisory).

Upgrade FileBrowser to version 2.63.19 or later, which fixes the scope-ownership check by performing a case-insensitive comparison using an anchored regex pattern ((?i)^<scope>$) instead of an exact string match (GitHub Advisory). If immediate patching is not possible, disable the Signup and/or CreateUserDir features to prevent self-registration and automatic home directory creation. As an additional measure, consider migrating FileBrowser's root to a case-sensitive filesystem if operationally feasible. Administrators should also audit existing databases for scope entries that differ only in case and manually resolve any shared physical directories, as the patch does not retroactively fix already-colliding accounts (Github Advisory DB).

The vulnerability was reported by researcher luoy16002-svg and remediated by FileBrowser maintainer hacdias (GitHub Advisory). VulnCheck assigned the CVE and published an advisory noting the authentication bypass nature of the flaw (VulnCheck Advisory). CISA-ADP reviewed the vulnerability and added an SSVC assessment classifying technical impact as "total," reflecting the severity of the cross-account file access (NVD). No significant broader media coverage or notable social media discussion has been identified at this time.