Filebrowser versions up to 2.63.23 do not delete share records when a shared file is renamed. The share record is keyed by the file path, so after a rename the record stays but the original file path becomes empty, causing a 404. When a new unrelated file later appears at that path – via re‑upload, another user with create permission, or an automated hook – the stale public share link serves that new file under the original link’s password and expiry, unintentionally exposing it. The flaw is a classic example of implicit authorization (CWE‑459) that can lead to information disclosure to anyone who holds the stale link.

The vulnerability affects the Filebrowser application distributed by the vendor filebrowser. All releases up to and including 2.63.23 are vulnerable. No specific sub‑versions are listed, so any unpatched installation in that version range is at risk.

The CVSS score is 2.3, indicating low severity by metrics, and the EPSS score is not available. The vulnerability is not listed in the CISA KEV catalog. The attack does not require complex conditions; it only needs an authenticated user able to rename a shared file and an ability to create or overwrite files at the original path. The likely vector is user‑driven file management via the UI or API. While exploitation is considered low risk, the potential impact is precise information disclosure of any file placed at a previously shared location, which can be costly when public share links are enabled.