Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GHSA-5ww9-jg6q-38r7 — filebrowser

Fix: filebrowser/filebrowser@0231b7e

GHSA-5ww9-jg6q-38r7 is a CWE-639 vulnerability in github.com/filebrowser/filebrowser. A fix is available for github.com/filebrowser/filebrowser — see the affected versions and patch details below.

File Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix

Also known asCVE-2026-54097GO-2026-5159
Published
Jun 12, 2026
Updated
Jul 21, 2026
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed
Exploitation data as of Sep 25, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-5ww9-jg6q-38r7.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs36th percentile — riskier than 36% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

2 pkgs affected
🐹github.com/filebrowser/filebrowser🐹github.com/filebrowser/filebrowser/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

Details

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.

Impact

  • Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators.
  • Availability: effective denial-of-service of the share-link feature — a cooperating (or malicious) low-priv user can wipe the bulk of existing share links by iterating a short set of one- and two-character prefixes.

Affected Packages

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/filebrowser/filebrowserall versionsNo fix
🐹Gogithub.com/filebrowser/filebrowser/v2all versions2.63.6go get github.com/filebrowser/filebrowser/v2@v2.63.6

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filebrowser/filebrowser, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    No patched version of github.com/filebrowser/filebrowser has shipped for GHSA-5ww9-jg6q-38r7 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-5ww9-jg6q-38r7 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-5ww9-jg6q-38r7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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. ### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted
O3 Security · Impact-Aware SCA

Is GHSA-5ww9-jg6q-38r7 in your dependencies?

O3 Security finds GHSA-5ww9-jg6q-38r7 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

Scan my dependencies How O3 SCA works
GHSA-5ww9-jg6q-38r7: filebrowser | O3 Security