CVE-2026-82237: filebrowser through 2.63.23 Stale Share Link via File Rename
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.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to unintended file disclosure?
Instances that have public share links for files are exposed if a shared file is renamed and a new file is later created at the original path. The new file can be uploaded by any user with create permission or created by a hook.
What must happen for a stale link to expose a new file?
A file with an existing share record must be renamed rather than deleted, leaving the path-keyed share record behind. A different file must then appear at the original path; the old public link will serve it using the original link's password and expiry settings.
How can administrators identify potentially affected shares?
Look for share links whose original files were renamed and whose links now return 404 because the original path is empty. If a file has subsequently been created at one of those original paths, the stale link may expose that file.
What can be done before patching?
Avoid renaming files that have public share links; remove the share record before renaming when possible. Review stale links associated with renamed files and ensure no unrelated file is created at their original paths.