filebrowser CVE-2026-82237

Three specific conditions must align for exploitation: (1) A file must have been shared via filebrowser's public share feature at a specific path, and that share link distributed to at least one external party. (2) The original shared file must be renamed (not deleted) - deletion correctly removes the share record, but rename does not. (3) A new, unrelated file must subsequently appear at the exact original path, either through re-upload by any user with create permissions on that directory, via an automated hook, or through a restore/sync operation. The attacker's role requires no special privilege at exploitation time - they need only possess the original share URL. The limiting factors are the multi-step sequence dependency (all three conditions must occur in order), the requirement that a low-privileged authenticated user initiate the original share, and that the new file must happen to land at precisely the original path.

The CVSS 4.0 score of 2.3 accurately reflects the compounded preconditions: AC:H indicates high attack complexity, and AT:P captures the partial attack requirements - specifically that a new file must independently arrive at the original path for the stale share to activate. PR:L confirms that exploitation setup requires at minimum a low-privilege authenticated user to create the initial share and trigger the rename. Real-world risk is therefore situational: in single-user or tightly controlled deployments the conditions are unlikely to align, but in multi-user environments where different users can upload to shared directories, the conditions could arise naturally and without anyone realizing the old share link remained active. There is no EPSS data provided and no KEV listing, consistent with the low base score. The risk is primarily an unexpected information disclosure affecting data confidentiality (VC:L), with no integrity or availability impact. The primary danger is that neither the file owner who renamed the original nor the user who uploads the new file is alerted that a public share link is already watching that path.

A user shares a sensitive document at /reports/q1-financials.xlsx and distributes the public link to external parties; they then rename the file to /reports/q1-financials-final.xlsx, believing the old link is now dead (it returns 404). A colleague later uploads a new /reports/q1-financials.xlsx containing updated, potentially more sensitive data. Anyone who retained the original share link can now download this new document - complete with the original password and expiry - without any explicit share grant having been made. No public exploit code is required; the attack surface is the browser address bar.