CVE-2026-61874: filebrowser incorrect authorization via path normalization in DeleteWithPathPrefix

CVE-2026-61874 · Severity: low · CVSS 3.1 · Published 2026-07-12

File Browser, a web-based file management utility, contains a flaw that can lead to unintended data exposure. When a user deletes a folder that was previously shared publicly, the system may fail to deactivate the public sharing link if the deletion request includes a trailing slash. If a folder with the same name is created later, the old public link becomes active again, potentially exposing new, private files to anyone who has the original link.

Technologies: File Browser. Vendors: File Browser.

Quick answers

Is CVE-2026-61874 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-61874 being exploited in the wild.
How severe is CVE-2026-61874?
Low severity, with a CVSS score of 3.1, published 12 July 2026.
Which products and versions are affected?
File Browser < 2.63.17.
Is there a fix for CVE-2026-61874?
No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is CVE-2026-61874 attacked?
It is attacked over the network, in a network appliance.
Am I affected by CVE-2026-61874?
Check whether you run File Browser at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

A vulnerability exists in filebrowser's Bolt storage backend where the `DeleteWithPathPrefix` function fails to normalize paths before performing a database prefix query. When an authenticated user deletes a directory using a path with a trailing slash (e.g., '/a/'), the database query for the share index misses the exact share record (e.g., '/a'). Consequently, the directory is deleted but the public share metadata remains in the database. If a directory is later recreated at the same path, the dormant public share becomes active, exposing the new directory's contents to unauthenticated users via the original share hash. This issue is fixed in version 2.63.17 by ensuring paths are normalized before the index query.

Affected products

  • filebrowser filebrowser < 2.63.17

Timeline

  • 2026-06-28: advisory: GitHub Security Advisory published
  • 2026-07-12: disclosed: NVD publication date

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.