Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-14T13:19:31.030Z",
  "pubdate": "2026-09-14T13:19:31.030Z",
  "executiveSummary": "An incorrect authorization vulnerability exists in File Browser versions 2.5.0 through 2.63.23 within the direct-upload endpoint, specifically in the resourcePostHandler function located in http/resource.go.\nThe flaw allows an authenticated non-administrator user with limited Create and Modify permissions to execute arbitrary recursive directory deletions.\nThe vulnerability stems from an insecure failure-cleanup path in the direct-upload handler that triggers Fs.RemoveAll on a target path when a POST request with ?override=true is directed at an existing directory.\nBecause this cleanup mechanism lacks the necessary permission checks (Perm.Delete) and security validations (checkDescendants) applied to standard delete operations, it bypasses access control restrictions.\nAlthough exploitation is scoped to the user's filesystem boundary via ScopedFs.RemoveAll, the vulnerability allows unauthorized removal of protected directories and files within that scope.\nThis presents a significant risk to data integrity and availability, as attackers can bypass rule-denied protections to recursively destroy entire file trees.\nThere is currently no patched version available to remediate this flaw.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of directory targets within the direct-upload endpoint managed by resourcePostHandler in http/resource.go. When a client sends a POST request with the ?override=true parameter targeting a directory, the application attempts to invoke writeFile. Since standard file write operations cannot open a directory for writing, the system initiates a failure-cleanup routine.\nThis cleanup path explicitly calls Fs.RemoveAll on the requested path. Critically, this routine fails to verify the user's permissions, omitting both the Perm.Delete requirement and the checkDescendants security logic—safeguards that are correctly implemented in the application's standard delete and patch handlers.\nExploitation requires authenticated access to the File Browser instance with, at minimum, Create and Modify permissions. By targeting an existing directory with the direct-upload handler and the override parameter, an attacker triggers the faulty code path.\nThe attack flow proceeds as follows: 1) The attacker initiates an HTTP POST request to the direct-upload endpoint targeting a path they intend to delete. 2) The inclusion of the ?override=true query parameter triggers the internal write process. 3) The server attempts to open the specified target as a file, which fails because the target is a directory. 4) The server's error-handling logic catches the failure and enters the cleanup routine. 5) Fs.RemoveAll is invoked on the attacker-supplied path, resulting in the recursive deletion of the directory and all of its contents.\nThe impact is significant because the logic bypasses standard security rules; it allows the removal of files that have been explicitly denied by the system's rule-based permissions. While ScopedFs.RemoveAll enforces the user's scope, preventing the deletion of files outside the user's assigned directory, the attacker can effectively destroy any subdirectories and files they have access to within that scope, regardless of specific 'deny' rules on those files.\nThe vulnerable code was introduced in version 2.5.0 and persists through 2.63.23. The lack of proper validation on the cleanup path ensures that the operational logic of the file system interaction remains insecure during the failure state of the direct-upload process."
}