CVE-2026-82237 in Filebrowser
Summary
by MITRE • 08/28/2026
filebrowser through 2.63.23 does not remove share records when a shared file is renamed (only deletion triggers share cleanup). The share record is keyed by path, so it survives the rename and remains dormant (returning 404 while the path is empty). When any new, unrelated file later appears at the original shared path — via re-upload, another user with create permission, or a hook — the stale public share link serves that new file under the original link's password and expiry settings, unexpectedly exposing it.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in FileBrowser versions up to 2.63.23 represents a critical logic flaw within the application’s shared resource management subsystem, specifically concerning the lifecycle of public share records relative to file system operations. This issue stems from an incorrect coupling between the persistence layer for share metadata and the underlying filesystem path resolution mechanism. When a user initiates a rename operation on a file that has been publicly shared, the application fails to invalidate or remove the corresponding entry in its internal database of active shares. The architectural design relies heavily on the absolute file system path as the primary key for identifying valid share targets. Consequently, while the physical file moves from one directory location to another, the stale record remains anchored to the original, now-vacant path string within the application’s state management layer.
From a technical perspective, this behavior creates a race condition and data integrity issue where the security context of the old resource is erroneously detached from its content but retained in the access control logic. The share record becomes dormant because requests directed at the original path result in a forty-four hundred not found error due to the absence of the file at that specific location. However, this state is transient and dangerous. If any subsequent action results in a new file being created or uploaded to that exact same filesystem path—whether through re-upload by the original user, creation by another authorized user with write permissions, or execution of an automated hook—the application’s routing logic will associate the existing stale share record with this newly placed content. The system does not verify whether the current inode and metadata match those originally intended for sharing; it simply checks if a valid share exists for that path string.
The operational impact of this vulnerability is severe, leading to unauthorized information disclosure through privilege escalation via path manipulation. An attacker or any external observer possessing the original public link can access sensitive data belonging to entirely different users or systems once the path has been repurposed. This exposure occurs without requiring authentication bypass techniques such as brute force or credential stuffing; instead, it exploits a logical oversight in resource lifecycle management. The new file is served under the password protection and expiration settings of the original share, meaning that if the original link was set to expire far in the future or had no password, the newly exposed data remains accessible indefinitely without additional safeguards. This scenario effectively allows for lateral movement within shared directories where one user’s stale share can inadvertently expose another user’s confidential documents simply by virtue of filename collision and path reuse.
This vulnerability aligns with CWE-672, which describes the use of outdated or incorrect references to resources, as well as CWE-841, Improper Enforcement of Behavioral Workflow, because the application fails to enforce the correct sequence of state changes when a resource is modified. In terms of offensive security frameworks, this behavior can be categorized under ATT&CK technique T1074, Data Staged, specifically involving local data staging where an attacker might manipulate file paths to stage malicious content or exfiltrate data via shared links that have been hijacked through path reuse. It also touches upon CWE-284, Improper Access Control, as the access control mechanism fails to properly associate permissions with the current state of the resource rather than a historical identifier.
Mitigation strategies must focus on decoupling share records from volatile filesystem paths and implementing robust lifecycle management for shared resources. The most effective remediation is to refactor the database schema so that share records are keyed by unique, immutable identifiers such as file UUIDs or inode numbers rather than mutable string-based file paths. This ensures that a rename operation does not break the association between the share record and the actual data object. Additionally, the application should implement event-driven cleanup mechanisms where any modification to a shared resource’s metadata triggers an immediate validation check against existing public shares. If a mismatch is detected or if the original path becomes vacant, the system must automatically revoke or update the associated share records to prevent them from being reapplied to unrelated content. Upgrading to patched versions of FileBrowser that address this logic flaw is essential for maintaining data confidentiality in multi-user environments where shared links are frequently utilized.