CVE-2026-54096 in File Browser
Summary
by MITRE • 06/25/2026
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.7, `POST /api/share/` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/`. This vulnerability is fixed in 2.63.7.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/26/2026
This vulnerability resides in File Browser's handling of public share creation and validation processes, representing a directory traversal and access control flaw that allows unauthorized exposure of files through manipulated share records. The issue stems from the lack of proper validation during the share creation endpoint POST /api/share/ where the system accepts authenticated requests for arbitrary file paths without verifying whether those paths actually exist at the time of share creation. This design flaw creates a race condition scenario where a share record is created for a non-existent path, only to become immediately valid when a file is subsequently created at that exact location.
The technical implementation of this vulnerability enables an attacker with authentication credentials to manipulate the share system by specifying any arbitrary file path during share creation. When the system processes this request, it creates a public share record without performing existence checks on the target path, storing the record in the system's share database. This behavior violates fundamental security principles of access control and resource validation, creating a scenario where share records become active upon file creation rather than being validated at creation time. The vulnerability is particularly concerning because it operates through legitimate authenticated API endpoints, making detection more challenging.
The operational impact of this vulnerability allows attackers to gain unauthorized access to files that they would normally not have permission to view. Once a malicious user creates a share record for a path that doesn't currently exist, any subsequent file creation at that exact location automatically makes the previously created share valid and accessible through the GET /api/public/dl/ endpoint. This enables attackers to potentially access sensitive files, including those in restricted directories, by simply creating shares for paths where they expect files to be created. The vulnerability essentially creates a backdoor mechanism for accessing files through manipulated share records rather than proper access controls.
The fix implemented in version 2.63.7 addresses this issue by introducing proper validation checks during the share creation process. The system now verifies that target file paths exist before creating public share records, preventing the creation of invalid share references that could later become valid upon file creation. This change aligns with security best practices and common controls recommended in industry standards such as those outlined in CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-732 (Incorrect Permission Assignment for Critical Resource). From an ATT&CK framework perspective, this vulnerability relates to T1078 (Valid Accounts) and T1566 (Phishing) as it enables attackers to leverage legitimate authenticated access to create unauthorized file exposure opportunities.
Organizations using File Browser should ensure immediate deployment of version 2.63.7 or later to remediate this vulnerability, as the flaw allows for privilege escalation through share manipulation. The security implications extend beyond simple file access, potentially enabling data exfiltration and information disclosure attacks where attackers can systematically create shares for sensitive directories and wait for files to be created at those locations. Additionally, administrators should review existing share records for paths that may have been manipulated in the past, as these could potentially remain valid and accessible even after the immediate vulnerability is patched. The fix demonstrates the importance of proper input validation and resource existence checking in web applications, particularly those handling file management operations where access controls must be rigorously enforced at all stages of the request lifecycle.