CVE-2026-72836 in FileBrowser
Summary
by MITRE • 08/14/2026
FileBrowser before 2.63.19 does not account for case-insensitive filesystems when checking home directory ownership during self-registration. When Signup and CreateUserDir are enabled and FileBrowser's root is on a case-insensitive filesystem (confirmed on Windows/NTFS), two self-registered usernames that differ only in letter case (e.g., CaseVictim and casevictim) are stored as distinct accounts but resolve to the same physical home directory, because the scope-ownership check compares the persisted scope as an exact case-sensitive string. A second registrant can therefore read, overwrite, and delete another account's files through authenticated HTTP endpoints, without needing an existing account or victim interaction.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
This vulnerability exists in FileBrowser versions prior to 263.19 and represents a critical access control flaw that exploits the mismatch between case-sensitive account management and case-insensitive filesystem behavior. The issue manifests when both Signup and CreateUserDir features are enabled, creating a scenario where the system fails to properly validate home directory ownership during the self-registration process. When FileBrowser operates on case-insensitive filesystems such as Windows NTFS, the application's scope-ownership validation mechanism performs exact case-sensitive string comparisons against persisted account scopes without accounting for the filesystem's case-insensitive nature.
The technical implementation flaw stems from how FileBrowser handles user registration and directory management within its authentication system. During self-registration, the application creates account directories but does not properly enforce uniqueness checks that consider case-insensitive filesystem behavior. This allows attackers to register accounts with usernames that differ only in letter casing, such as CaseVictim and casevictim, which are treated as distinct accounts at the application level but map to identical physical directories on case-insensitive systems. The vulnerability specifically targets the scope-ownership validation logic that should prevent multiple accounts from sharing the same home directory path.
The operational impact of this vulnerability is severe and directly enables unauthorized data access and manipulation across user accounts. An attacker who registers an account with a case variant of an existing username can subsequently access, modify, or delete files belonging to the original account through authenticated HTTP endpoints without requiring any victim interaction or pre-existing account access. This creates a privilege escalation scenario where a second registrant gains full read-write-delete access to another user's data simply by exploiting the case-insensitive filesystem behavior combined with the application's case-sensitive scope validation. The vulnerability effectively allows for account takeover and data compromise across all authenticated endpoints.
This vulnerability aligns with CWE-284 Access Control Issues, specifically addressing improper access control mechanisms that fail to properly validate resource ownership in multi-user environments. It also relates to ATT&CK technique T1078 Valid Accounts, as the attack exploits legitimate user registration processes to gain unauthorized access to other accounts' data. The root cause involves inadequate input validation and scope management during account creation, where the system fails to implement proper case-insensitive uniqueness constraints that would prevent multiple accounts from mapping to identical filesystem paths.
Mitigation strategies should focus on implementing comprehensive case-insensitive account name validation during registration processes, ensuring that duplicate usernames regardless of case are properly detected and rejected. Organizations should upgrade to FileBrowser version 2.63.19 or later where this vulnerability has been addressed through improved scope-ownership validation logic that accounts for filesystem case sensitivity. Additionally, system administrators should implement monitoring solutions to detect anomalous account registration patterns and consider disabling CreateUserDir functionality if the root directory is hosted on case-insensitive filesystems until proper patches are applied. The fix requires modifications to the core authentication module to ensure that account creation logic properly validates against existing accounts using case-insensitive comparison methods while maintaining backward compatibility with legitimate use cases.