GHSA-5WW9-JG6Q-38R7

Vulnerability from github – Published: 2026-06-12 21:00 – Updated: 2026-07-21 14:44
VLAI
Summary
File Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix
Details

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.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.63.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.63.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54097"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T21:00:55Z",
    "nvd_published_at": "2026-06-25T19:16:41Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA 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 \u2014 including the administrator \u2014 by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user\u0027s stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim\u0027s share links are irrevocably wiped.\n\n### Details\n`resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling:\n\n```go\n// http/resource.go\nerr = d.store.Share.DeleteWithPathPrefix(file.Path)\n```\n\n`file.Path` here is the *logical* path from the URL of the deleting user\u0027s request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend:\n\n```go\n// storage/bolt/share.go\nfunc (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error {\n    var links []share.Link\n    if err := s.db.Prefix(\"Path\", pathPrefix, \u0026links); err != nil {\n        return err\n    }\n    for _, link := range links {\n        err = errors.Join(err, s.db.DeleteStruct(\u0026share.Link{Hash: link.Hash}))\n    }\n    return err\n}\n```\n**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 \u0026\u0026 !d.user.Perm.Admin \u2192 403`. The file-deletion side-effect path is the only location that bypasses this rule.\n\n\n\n### Impact\n- Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators.\n- Availability: effective denial-of-service of the share-link feature \u2014 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.",
  "id": "GHSA-5ww9-jg6q-38r7",
  "modified": "2026-07-21T14:44:53Z",
  "published": "2026-06-12T21:00:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-5ww9-jg6q-38r7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54097"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/0231b7ebdfbe77a6c54027d30c4856c3fd81ee4d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…