CVE-2026-82236 in File Browser
Summary
by MITRE • 08/28/2026
File Browser versions from 2.63.6 through 2.63.23 fail to clean up public share links when a privileged user deletes another user's shared file. Attackers can access the surviving share link to retrieve new unrelated content uploaded to the same path without authentication.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability in File Browser versions ranging from 2.63.6 through 2.63.23 represents a critical failure in session and resource lifecycle management, specifically concerning public sharing mechanisms. This flaw stems from an improper cleanup procedure when privileged users, such as administrators or account owners with elevated permissions, delete files that have been shared publicly by other users within the system. The core technical issue lies in the application's handling of persistent access tokens associated with these shares. When a file is deleted via a privileged action targeting another user's content, the backend logic fails to invalidate or remove the corresponding public share link metadata from its database or cache structures. Consequently, the unique identifier and URL pattern that grant anonymous access remain active despite the underlying resource being removed. This creates a state where the system retains references to non-existent resources while simultaneously allowing those references to be resolved against new data introduced into the same storage path.
From an operational perspective, this vulnerability enables unauthorized information disclosure through link persistence and path reuse. An attacker who has obtained or guessed a valid public share URL can continue to access it even after the original file has been deleted by an administrator. More critically, if another user uploads a new file with the exact same filename to that specific directory structure, the system may serve this new content when the old link is accessed. This occurs because many web servers and application frameworks map URLs directly to filesystem paths or database records without strictly enforcing isolation between historical share tokens and current file states in all code paths. The result is a scenario where sensitive data uploaded by unrelated users becomes accessible to anyone possessing the stale public link, bypassing authentication controls entirely.
This flaw aligns with CWE-613, which describes insufficient session expiration, as well as CWE-200, concerning exposure of sensitive information to an unauthorized actor. In terms of offensive security frameworks, this vulnerability facilitates exploitation via ATT&CK technique T1530, Data from Local System Exfiltration, specifically through the use of existing shared resources that were not properly revoked. The attack vector is primarily remote and requires no authentication for the initial access if the public link was previously known or discoverable, making it particularly dangerous in environments where users share files externally with clients or partners who may retain links indefinitely.
Mitigation strategies must focus on immediate patching to version 2.63.24 or later, which addresses this logic error by ensuring that deletion events trigger a comprehensive cleanup of all associated public sharing records regardless of the user role initiating the delete action. Administrators should also audit existing shared links for any lingering access points if they are running an unpatched version and cannot immediately upgrade. Implementing strict path isolation or using unique identifiers rather than predictable filenames in share URLs can further reduce the risk of cross-user data leakage due to filename collisions. Regular security reviews of file management systems should include testing for proper invalidation of public tokens upon resource deletion, ensuring that access control lists are synchronized with actual storage state changes.