GHSA-QQQM-5547-774X: Unauthenticated Path Traversal in FileBrowser Quantum PATCH Handler

GHSA-QQQM-5547-774X is a critical path traversal vulnerability affecting the FileBrowser Quantum application, specifically within the Go backend package github.com/gtsteffaniak/filebrowser/backend. The vulnerability resides in the HTTP handler responsible for processing bulk file modifications via the public API. An attacker can exploit this flaw to bypass intended directory restrictions and interact with arbitrary files on the host filesystem.

This issue represents a secondary instance of an architectural pattern previously identified and patched under CVE-2026-44542. While the prior vulnerability affected the bulk DELETE endpoint, the identical vulnerable logic remained exposed in the PATCH handler. The attack surface is exposed whenever a user creates a public share link with the "Allow Modify" permission enabled.

Exploitation requires no authentication to the primary web interface, provided the attacker possesses the valid public share hash. The underlying weakness is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), as the application fails to adequately sanitize user-supplied path sequences before using them in filesystem operations.

The root cause is an order-of-operations flaw within the publicPatchHandler function located in backend/http/public.go. The handler receives a JSON payload containing fromPath and toPath variables intended to dictate file move, copy, or rename operations. Before these paths are checked for traversal sequences, they are concatenated with the trusted root directory path using the utils.JoinPathAsUnix function.

The utils.JoinPathAsUnix utility acts as a wrapper for the standard library filepath.Join function. In Go, filepath.Join automatically invokes filepath.Clean, which lexically resolves and collapses dot-dot (..) segments. As a result, any traversal sequences injected by the user are resolved against the trusted share path during the join operation.

Following this operation, the application passes the joined and cleaned path to resourcePatchHandler, which subsequently executes utils.SanitizeUserPath. Because the traversal sequences were already resolved and eliminated by filepath.Clean, the sanitizer only observes the final absolute path. The sanitizer fails to detect any malicious patterns, erroneously authorizing the filesystem operation outside the restricted directory boundary.

The vulnerability is evident when examining the data flow in backend/http/public.go prior to the fix implementation. The application iterates over the requested items and joins the user input with the share path. The resolution of the path occurs before the input is passed to the sanitization routine.

// Vulnerable implementation in publicPatchHandler
for i := range req.Items {
    req.Items[i].FromSource = sourceName
    // filepath.Join resolves '..' here before sanitization
    req.Items[i].FromPath   = utils.JoinPathAsUnix(d.share.Path, req.Items[i].FromPath) 
    req.Items[i].ToSource   = sourceName
    req.Items[i].ToPath     = utils.JoinPathAsUnix(d.share.Path, req.Items[i].ToPath)   
}
d.Data = req
// Sanitization happens AFTER the join inside resourcePatchHandler
status, err := resourcePatchHandler(w, r, d)

The resourcePatchHandler function then relies on utils.SanitizeUserPath to validate the safety of the path. The internal logic of SanitizeUserPath iterates through the path segments, explicitly looking for the literal string ... Because the join operation already collapsed these sequences, the function finds no traversal artifacts and returns no error.

The patch corrects this architectural flaw by strictly enforcing sanitization on the raw user input before any path concatenation occurs. The revised logic ensures that utils.SanitizeUserPath evaluates the initial payload, successfully detecting and rejecting traversal sequences.

// Patched implementation
for i := range req.Items {
    cleanPath, err := utils.SanitizeUserPath(req.Items[i].FromPath)
    if err != nil {
        return http.StatusBadRequest, err
    }
    req.Items[i].FromPath = utils.JoinPathAsUnix(d.share.Path, cleanPath)
}

Exploiting GHSA-QQQM-5547-774X requires network access to the FileBrowser API and knowledge of a public share link hash. The targeted share must be configured with the AllowModify=true parameter. The attacker does not need an active user account or session token.

The attacker constructs an HTTP PATCH request directed at the /public/api/resources endpoint, appending the known share hash as a query parameter. The body of the request contains a JSON array specifying the desired file action, such as rename. The attacker populates the fromPath attribute with the relative traversal sequence targeting the desired file on the host operating system.

PATCH /public/api/resources?hash=<public-share-hash> HTTP/1.1
Content-Type: application/json
 
{
  "action": "rename",
  "items": [
    {
      "fromSource": "default",
      "fromPath": "../../etc/passwd",
      "toSource": "default",
      "toPath": "stolen_config.txt"
    }
  ]
}

Upon receiving the payload, the server interprets the relative path, executes the bypass, and relocates the targeted file into the public share directory. The attacker subsequently downloads the file using standard GET requests against the public share.

The vulnerability carries a CVSS v4.0 base score of 9.1, reflecting a critical severity level. The primary security impact is the complete loss of confidentiality and integrity for files accessible to the user context executing the FileBrowser process. The ability to arbitrarily read and write files frequently facilitates complete system compromise.

By moving sensitive files into the public share, attackers can exfiltrate cryptographic keys, database credentials, and user password hashes. The attacker executes the retrieval without generating authentication failures or leaving distinct access logs on the target file itself, as the application handles the file read operation natively.

Furthermore, the vulnerability permits stored data manipulation by allowing an attacker to rename uploaded files over critical system paths. An attacker can upload a malicious binary or authorized keys file to the share, then utilize the PATCH endpoint to overwrite /etc/shadow, ~/.ssh/authorized_keys, or application configuration files. This attack vector guarantees unauthenticated remote code execution or persistent access to the host machine.

The primary remediation strategy requires updating FileBrowser Quantum to a patched release. Administrators must deploy the application version incorporating commit 28e9b81e438e or later. Verify the deployed pseudo-version matches 0.0.0-20260518193514-28e9b81e438e to confirm the patch is active.

If immediate patching is unfeasible, administrators should review all active public share links within the application. The "Allow Modify" permission should be revoked from all public links, restricting users to read-only access. This configuration change completely mitigates the attack vector against the PATCH endpoint.

Security teams can also deploy Web Application Firewall (WAF) rules to inspect incoming HTTP requests. The WAF should block PATCH requests directed at /public/api/resources that contain ../ sequences within the JSON payload. This detection mechanism serves as a defense-in-depth measure, though native application patching remains the mandatory long-term solution.