CVE-2026-90929 in File Browser
Summary
by MITRE • 09/14/2026
File Browser versions >= 2.5.0 and <= 2.63.23 contain an incorrect authorization flaw in the direct-upload endpoint (resourcePostHandler in http/resource.go). Unlike the TUS upload handler, the direct-upload handler does not reject a target that is an existing directory; a POST with ?override=true aimed at a directory fails inside writeFile (a directory cannot be opened for writing) and the failure-cleanup path then calls Fs.RemoveAll on the request path, recursively deleting the entire tree. This cleanup is gated by neither the Perm.Delete permission nor the checkDescendants rule walk applied by the delete and patch handlers, so an authenticated non-administrator holding only the default Create and Modify permissions can delete directories they are not authorized to delete, including rule-denied files within them. Deletion remains confined to the user's scope because ScopedFs.RemoveAll still enforces the scope guard. The faulty cleanup was introduced in v2.5.0; no patched version is available.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in File Browser versions ranging from 2.5.0 through 2.63.23 represents a critical authorization bypass rooted in flawed error handling logic within the direct-upload endpoint, specifically located in the resourcePostHandler function found in http/resource.go. This flaw allows authenticated users with limited privileges to perform unauthorized destructive actions against directory structures that they are not permitted to delete under normal operational circumstances. The core of the issue lies in the disparity between how different upload handlers manage target paths and error states. While the TUS upload handler correctly rejects targets that are existing directories, preventing any further processing or side effects, the direct-upload handler proceeds with an attempt to write data directly into a directory path when such a request is made. This architectural inconsistency creates a specific attack vector where the system's internal cleanup mechanisms are triggered inappropriately due to a lack of proper validation and permission checks during the failure recovery phase.
When an authenticated user submits a POST request with the override parameter set to true targeting an existing directory, the underlying writeFile function fails because standard file systems do not allow opening a directory for writing as if it were a regular file. This expected technical failure triggers a cleanup routine designed to remove any partially created or erroneous artifacts from the failed operation. However, this cleanup logic invokes Fs.RemoveAll on the request path without verifying whether the user possesses the necessary Perm.Delete permission or adhering to the checkDescendants rule walk that is strictly enforced by other handlers such as delete and patch operations. Consequently, an attacker who holds only default Create and Modify permissions can exploit this gap to recursively delete entire directory trees within their scope, including files and subdirectories that are explicitly protected by access control rules denying deletion. This behavior effectively bypasses the intended security boundaries established for non-administrator users, allowing them to destroy data they should be restricted from modifying or removing entirely.
The operational impact of this vulnerability is severe in terms of data integrity and availability within multi-tenant environments where File Browser manages shared storage resources. Although the damage is confined to the user's assigned scope due to the enforcement of scoped access controls by ScopedFs.RemoveAll, an attacker can still cause significant disruption by deleting large volumes of legitimate files or critical configuration directories that they are not authorized to manage. This capability undermines the principle of least privilege and compromises the reliability of file management operations for all users sharing the same storage backend. The vulnerability was introduced in version 2.5.0 and persists through version 2.63.23, with no patched release currently available from the vendor, leaving organizations relying on these versions exposed to this risk indefinitely unless they implement external mitigations or upgrade to a future corrected version once released.
From a classification perspective, this vulnerability aligns with CWE-862 Missing Authorization and CWE-754 Improper Check for Unusual or Exceptional Conditions within the software's error handling logic. The attack pattern corresponds to ATT&CK technique T1083 File and Directory Discovery combined with T1485 Data Destruction, as it involves identifying target directories and subsequently deleting them through an unauthorized code path. To mitigate this risk in the absence of a vendor patch, administrators should consider restricting direct-upload access for non-administrative users or implementing web application firewall rules that block POST requests to directory paths when override parameters are present. Additionally, enforcing stricter input validation on upload endpoints to reject attempts to target existing directories before any write operations occur can prevent the trigger condition entirely. Organizations must also review their internal backup and recovery procedures to ensure they account for potential mass deletions resulting from this specific exploitation vector until a permanent fix is deployed.