GHSA-MMPX-JH39-WRV6: Stored Cross-Site Scripting in FileBrowser Quantum via SVG Rendering

FileBrowser Quantum functions as a web-based file manager, allowing users to upload, manage, and share files. A core feature of this application is the ability to generate public share links for stored files. These files can be served directly to a user's browser for immediate viewing using the ?inline=true query parameter.

The vulnerability exists in how the application handles HTTP responses for inline content rendering. Specifically, the application sets the Content-Disposition: inline header without applying necessary security controls to the response. This configuration instructs the browser to render the file natively rather than prompting the user to download it.

Because the application serves these files from its primary origin, any active content within the rendered file executes in the context of the FileBrowser instance. The application fails to mitigate this behavior, lacking a Content Security Policy (CSP) header that would normally restrict script execution for untrusted user-uploaded files.

The underlying flaw is categorized as CWE-79: Improper Neutralization of Input During Web Page Generation, combined with CWE-693: Protection Mechanism Failure. The mechanism failure occurs in the backend HTTP handler responsible for file downloads and inline rendering.

Scalable Vector Graphics (SVG) files are XML-based documents capable of containing embedded JavaScript. The SVG specification allows for script execution through direct <script> tags or via event handlers such as onload. When a browser receives an SVG file with a Content-Type: image/svg+xml header and a Content-Disposition: inline header, it processes the document as a top-level execution context.

The FileBrowser Quantum backend routine setContentDisposition processes the incoming HTTP request and checks for the inline=true parameter. If present, it modifies the disposition type but returns the response without injecting a Content-Security-Policy header. The absence of this header permits the browser's rendering engine to parse and execute any JavaScript found within the SVG payload.

The vulnerability resides in the Go backend, specifically within the backend/http/download.go file. The setContentDisposition function is responsible for determining whether a requested file should be downloaded as an attachment or displayed inline based on the query parameters.

In the vulnerable implementation, the function simply toggled the disposition string. It did not alter the security posture of the HTTP response. The browser relies on the server to assert execution boundaries, and the server failed to provide them.

The patch applied in commit 6bfc3974192e954f71cc5d1cd04baaaec3b76383 introduces a direct mitigation for this specific rendering path. The developers implemented a CSP header to explicitly disable script execution when a file is requested inline.

// backend/http/download.go (Patched)
 
func setContentDisposition(w http.ResponseWriter, r *http.Request, fileName string) {
    dispositionType := "attachment"
    if r.URL.Query().Get("inline") == "true" {
        dispositionType = "inline"
+       // Inline SVG (and similar) can execute embedded scripts when opened as a top-level document; 
+       // match upstream filebrowser mitigation.
+       w.Header().Set("Content-Security-Policy", "script-src 'none'")
    }
    // ...
}

By injecting w.Header().Set("Content-Security-Policy", "script-src 'none'"), the server explicitly instructs the browser that no scripts are permitted to run within this document. The browser's CSP engine enforces this policy during the parsing phase, neutralizing any <script> tags or event handlers present in the SVG file.

Exploitation requires an attacker to upload a crafted SVG file to the FileBrowser instance. The attacker must have sufficient privileges to upload files, though the required privilege level depends on the specific deployment configuration. Once the file is hosted, the attacker leverages the application's sharing functionality.

The attacker creates an SVG file containing a malicious JavaScript payload. A standard proof-of-concept payload utilizes the onload event handler within the main svg tag. This ensures the JavaScript executes immediately upon the document rendering in the victim's browser.

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)">
    <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</svg>

After uploading the payload, the attacker generates a public share link. The attacker appends the ?inline=true query parameter to the URL and distributes it to the intended victim. When the victim navigates to the provided link, their browser fetches the file, observes the inline disposition, and renders the XML. The embedded JavaScript executes within the domain context of the FileBrowser application.

The successful exploitation of this vulnerability yields arbitrary JavaScript execution in the context of the FileBrowser application. Because the execution occurs within the application's origin, the attacker bypasses the Same-Origin Policy (SOP) restrictions that normally separate different web properties.

An attacker can utilize this access to interact with the application on behalf of the victim. If the victim is an authenticated user or an administrator, the attacker's script can issue XMLHttpRequests (XHR) to the backend API. This access permits the modification of files, deletion of data, or the creation of new administrative accounts.

The payload can also access sensitive data stored within the browser. This includes reading session tokens stored in localStorage, sessionStorage, or non-HttpOnly cookies. The extracted tokens can be exfiltrated to an attacker-controlled server, leading to full session hijacking.

The primary remediation for this vulnerability is updating the FileBrowser Quantum deployment to a patched version. The maintainer released fixes in versions v1.3.1-stable and v1.3.9-beta. These updates apply the CSP header fix natively within the application binary.

If immediate patching is not feasible, administrators can mitigate the vulnerability at the reverse proxy layer. Web servers such as NGINX or Apache can be configured to dynamically inject the Content-Security-Policy: script-src 'none' header based on the request URL. Specifically, the proxy can inspect the query parameters and append the header if inline=true is detected.

Furthermore, administrators should review the necessity of allowing public shares or inline rendering. Restricting the inline parameter at the WAF level prevents the vulnerability from being triggered entirely, forcing all shared files to download as attachments rather than executing in the browser.