Summary The remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2.

Details The issue stems from two flaws: 1. Tokenized download URLs are written into the persistent share model backend/http/share.go convertToFrontendShareResponse(line 63) s.DownloadURL = getShareURL(r, s.Hash, true, s.Token) 2. The public endpoint: GET /public/api/share/info returns shareLink.CommonShare without clearing DownloadURL.

Since Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability.

The previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL

PoC 1. Create a password protected share as an authenticated user

2. Copy the public share URL (the clipboard WITHOUT an arrow) http://yourdomain/public/share/yoursharedhash Example: http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw

3. Query the public share endpoint via curl request: curl 'http://yourdomain/public/api/share/info?hash=(your-share-hash)' -H 'Accept: /' Example: curl 'http://yourdomain/public/api/share/info?hash=2EBGbXgXg5dpw-nK0RG6vw' -H 'Accept: /' Response includes: { "shareTheme": "default", "title": "Shared files - test.md", "description": "A share has been sent to you to view or download.", "disableSidebar": false, "downloadURL": "http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D", "shareURL": "http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw", "enforceDarkLightMode": "default", "viewMode": "normal", "shareType": "normal", "sidebarLinks": [ { "name": "Share QR Code and Info", "category": "shareInfo", "target": "#", "icon": "qrcode" }, { "name": "Download", "category": "download", "target": "#", "icon": "download" }, { "name": "sourceLocation", "category": "custom", "target": "/srv/test.md", "icon": "" } ], "hasPassword": true, "disableLoginOption": false, "sourceURL": "/srv/test.md" } Note the response "hasPassword": true and downloadURL includes token= parameter

4. Take the downloadURL(seen in json data response) and replace \u0026 with & and paste link into Incognito or private browser to ensure cookies are not interfering Example: http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw&token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D

Browser downloads file immediately without requiring password

Impact An unauthenticated attacker can retrieve password protected shared files without the password. Results in authentication bypass, unauthorized file access and confidentiality compromise

Recommended Remediation Sanitize DownloadURL in public share info responses via commonShare.DownloadURL = "" before returning the json response in shareInfoHandler method located in backend/share.go

Structural fix, only generate tokenized URLs after successful password validation

Summary Stored XSS is possible via share metadata fields (e.g., title, description) that are rendered into HTML for /public/share/<hash> without context-aware escaping. The server uses text/template instead of html/template, allowing injected scripts to execute when victims visit the share URL.

Details The server renders public/index.html using text/template and injects user-controlled share fields (title/description/etc.) into HTML contexts. text/template does not perform HTML contextual escaping like html/template. Because share metadata is persistent, the payload becomes stored and executes whenever a victim opens the affected share page.

Relevant code paths: - backend/http/static.go (template rendering and share metadata assignment) - backend/http/httpRouter.go (template initialization) - frontend/public/index.html (insertion points for title/description and related fields)

PoC 1. Login as a user with share creation permission. 2. Create a share (POST /api/share) with malicious metadata: - title = </title><script>alert("xss")</script><title> 3. Open the resulting /public/share/<hash> URL in a browser. 4. Expected: Payload is safely escaped and displayed as text. 5. Actual: JavaScript executes in victim's browser (stored XSS).

Tested on Docker image: gtstef/filebrowser:stable (version v1.2.1-stable).

Impact - Arbitrary script execution in application origin. - Potential account/session compromise, CSRF-like action execution, data exfiltration from authenticated contexts. - Affects anyone (including unauthenticated visitors) opening the malicious share URL. - The XSS is stored and persistent — no social engineering beyond sharing the link is required.