Executive brief
filebrowser is a web-based file manager that allows users to create password-protected public sharing links for files. When a shared file is renamed, the system fails to remove the associated share record. This leaves the old public link dormant until a new, unrelated file is created at the original path—at which point the old link silently serves the new file without authentication, potentially exposing sensitive content that was never intended to be shared.
Technical details
The vulnerability is an incomplete cleanup issue (CWE-459) in filebrowser's share management logic. When a file is deleted, the share records matching that path are properly cleaned up via DeleteWithPathPrefix(); however, when a file is renamed, this cleanup is not performed. The share record is keyed by path and persists after the rename. The public link endpoint (withHashFile in http/public.go) resolves the stored path on every request, so it returns 404 while the old path is empty. When any new file later appears at that original path—whether re-uploaded by the owner, created by another user with permissions, or generated by a hook—the stale share link serves the new file under the original link's password and expiry constraints. Exploitation is opportunistic: an attacker holding an old share link waits for content to reappear at that path. No patch will be released, as the project is no longer maintained.
Affected products
- filebrowser filebrowser through 2.63.23
Timeline
- 2026-08-28: disclosed
- 2026-08-14: advisory: GitHub security advisory published