CVE-2026-54097High▾ TwilightFile Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 7.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.4%
0.4% → 0.4%
A low-privileged authenticated user of filebrowser (with create + delete permissions in their own isolated scope) can silently destroy share-link records belonging to any other user — including the administrator — by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored share.Link.Path. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped.
resourceDeleteHandler in http/resource.go cleans up any share records that reference a deleted file by calling:
// http/resource.go
err = d.store.Share.DeleteWithPathPrefix(file.Path)
file.Path here is the logical path from the URL of the deleting user's request (e.g. /a), not the absolute filesystem path. It is passed as-is to the bolt backend:
// storage/bolt/share.go
func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error {
var links []share.Link
if err := s.db.Prefix("Path", pathPrefix, &links); err != nil {
return err
}
for _, link := range links {
err = errors.Join(err, s.db.DeleteStruct(&share.Link{Hash: link.Hash}))
}
return err
}
Why the design contradicts this behavior. share.Link carries a UserID field and the application elsewhere treats shares as per-user owned resources. shareDeleteHandler explicitly enforces link.UserID != d.user.ID && !d.user.Perm.Admin → 403. The file-deletion side-effect path is the only location that bypasses this rule.
github.com/filebrowser/filebrowser <= 1.11.0github.com/filebrowser/filebrowser/v2 <= 2.63.5Upgrade to a patched release:
github.com/filebrowser/filebrowser/v2 2.63.6Connected by shared product, vendor, weakness, or advisory.
CVE-2025-53826HighFile Browser’s insecure JWT handling can lead to session replay attacks after logout
CVE-2026-23849Medium· 5.3File Browser Vulnerable to Username Enumeration via Timing Attack in /api/login
CVE-2026-54092High· 6.5File Browser has a DoS Vulnerability via Public Login API
CVE-2026-54093MediumFile Browser: FilePath traversal in download-as-zip/tar via Windows-style backslash separators in stored filenames
CVE-2026-54091High· 7.5File Browser has incorrect access control for public directory shares via rule path rebasing
CVE-2025-53893HighFile Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing