The 'Secure' Share That Wasn't: Bypassing FileBrowser Quantum

We all love self-hosted software. There is something deeply satisfying about spinning up a Docker container, pointing a reverse proxy at it, and knowing you own your data. FileBrowser Quantum is one of those darlings of the homelab community—a sleek, fast way to manage files over the web.

One of its core features is the ability to share files with outsiders. You generate a link, slap a password on it, and send it off. You trust the software to act as the bouncer, checking credentials before letting anyone into the VIP room.

But in versions prior to 1.1.3-stable, that bouncer was essentially asleep at the door. Worse, he wasn't just sleeping; he was taping the VIP wristbands to the outside of the club. CVE-2026-27611 isn't some complex memory corruption or a race condition that requires nanosecond precision. It is a classic, painful case of the backend oversharing information with the frontend—a vulnerability class that continues to haunt modern web applications.

To understand this vulnerability, we have to look at how modern Single Page Applications (SPAs) talk to their backends. When you visit a password-protected share link (e.g., https://files.example.com/share/AbCdEf), the frontend needs to know a few things before it renders the page. It asks the backend: "What is this file? Does it have a title? And most importantly, does it require a password?"

The backend answers this via the /public/api/shareinfo endpoint. In a secure implementation, this endpoint should return a minimal set of data: the filename, a flag saying passwordRequired: true, and maybe a checksum.

However, the developers of FileBrowser Quantum took a shortcut. Instead of creating a sanitized "Safe for Public" struct, they serialized the entire internal CommonShare object and sent it down the wire. This object contained everything the database knew about the share—including the downloadURL and the high-entropy token used to authorize the download. The frontend code was polite enough to ignore this token and show a password prompt, but an attacker with curl has no such manners.

Let's look at the smoking gun. The vulnerability lived in the shareInfoHandler. It took the hash from the URL and looked up the share details.

The Vulnerable Logic (Pseudo-code):

func shareInfoHandler(w http.ResponseWriter, r *http.Request) {
    hash := r.URL.Query().Get("hash")
    share, err := storage.GetShareByHash(hash)
    
    // CRITICAL MISTAKE:
    // The entire 'share' object is marshaled to JSON.
    // This includes internal fields like RealPath, Source, and Token.
    json.NewEncoder(w).Encode(share)
}

Because Go's JSON marshaler exports all public fields by default, and the CommonShare struct likely didn't have json:"-" tags on the sensitive fields, the API response looked something like this:

{
  "hash": "abcdef123456",
  "isPasswordProtected": true,
  "expiry": "2026-12-31",
  "downloadURL": "/api/raw?token=mz9...SecretToken...x1",
  "source": "/mnt/user_data/tax_returns/2025.pdf"
}

The fix, applied in commit c51b0ee, was to explicitly sanitize this object before encoding it. The developers effectively manually zeroed out the sensitive fields (Source, Path, and the generated link) ensuring only the metadata necessary for the UI was transmitted.

Exploiting this is trivially easy. You don't need Metasploit; you need a web browser's Developer Tools or a terminal.

Scenario: Alice shares a sensitive document with Bob, protected by a strong password. She sends Bob the link: https://quantum.local/share/S3cr3tH4sh.

Step 1: Reconnaissance Eve intercepts the link. She visits it in her browser and sees a password prompt. She doesn't know the password.

Step 2: The Bypass Eve opens her terminal and queries the API directly, using the hash from the URL.

curl -s "https://quantum.local/public/api/shareinfo?hash=S3cr3tH4sh" | jq

Step 3: Looting The server replies with the JSON blob we saw earlier. Eve spots the downloadURL parameter. She constructs her final download command, bypassing the password check entirely:

curl -O "https://quantum.local/api/raw?token=mz9...SecretToken...x1"

The server validates the token (which is valid!) and serves the file. The password protection logic was entirely client-side, relying on the user to be "honest" enough to not look at the hidden API response.

The impact here is a complete loss of confidentiality for shared files. Any file that was shared with the expectation of password protection is effectively public to anyone who possesses the share link.

This is particularly dangerous because users think they are secure. They might share PII, credentials, or backup archives over these links, believing the password provides a layer of encryption or access control. It does not.

Furthermore, because the API response often leaked internal file paths (e.g., /mnt/data/users/admin/passwords.txt), this vulnerability also serves as an information disclosure primitive, revealing the directory structure of the host server.

The remediation is straightforward: Update immediately.

If you are running FileBrowser Quantum versions prior to 1.1.3-stable or between 1.2.0-beta and 1.2.6-beta, you are vulnerable.

> [!WARNING] > Simply updating is not enough.

Because the tokens for existing shares were already generated and potentially exposed (e.g., logged in proxy logs, browser history, or indexed by bots if the link was public), you must regenerate your share links. The update fixes the code preventing future leaks, but it does not necessarily invalidate the tokens that were already leaked. Go into your dashboard, delete existing shares, and create new ones. This will generate fresh tokens that the patched API will essentially refuse to disclose.