| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/filebrowser/filebrowser | ≤ 1.11.0all versions | |
| github.com/filebrowser/filebrowser/v2 | ≤ 2.42.1all versions | |
| filebrowser | ≤ 2.32.0 |
Files managed by the File Browser can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible.
File owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file.
When sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on SHARE the following dialog opens allowing the file's owner to copy the share-link:
In fact, there is not one, but two links offered: A Download Link and an unnamed second one. They have the following format:
Apparently, the first of the two share links is that one that users are supposed to actually share, while the second one is a direct download link not protected by the password. This behavior is not documented anywhere or explained in the GUI, though.
There are multiple scenarios how an attacker might gain access to the unprotected link and, in consequence, to the shared file:
Using the first link results in an authorization error if no password is provided, as expected:
GET /api/public/share/6Gtw0xAw HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://filebrowser.local:8080/share/6Gtw0xAw
X-Auth:
X-SHARE-PASSWORD:
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Priority: u=4
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, no-store, must-revalidate
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline';
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 27 Mar 2025 10:59:12 GMT
Content-Length: 17
401 Unauthorized
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeOnly if the password is provided (via the X-SHARE-PASSWORD header), a proper response is given:
GET /api/public/share/6Gtw0xAw HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://filebrowser.local:8080/share/6Gtw0xAw
X-Auth:
X-SHARE-PASSWORD: 1234
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Priority: u=0
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline';
Content-Type: application/json; charset=utf-8
Date: Thu, 27 Mar 2025 10:59:15 GMT
Content-Length: 301
{"path":"","name":"dummy1.pdf","size":7703,"extension":".pdf","modified":"2025-03-27T15:11:45.101242449Z","mode":420,"isDir":false,"isSymlink":false,"type":"pdf","token":"voDK6j[...]"}
But it does not return the actual file content but rather an access token. This is the very same token that is already part of the second share URL and is used by the web application to recreate the actual download URL. If you are in possession of that one, no further password check is performed, and the content of the file is returned:
GET /api/public/dl/6Gtw0xAw?inline=true&token=voDK6j[...] HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Referer: http://filebrowser.local:8080/share/6Gtw0xAw
Upgrade-Insecure-Requests: 1
Priority: u=0, i
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private
Content-Disposition: inline
Content-Length: 7703
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline';
Content-Security-Policy: script-src 'none';
Content-Type: application/pdf
Last-Modified: Mon, 03 Mar 2025 15:11:45 GMT
Date: Thu, 27 Mar 2025 10:59:18 GMT
%PDF-1.4
%Çì¢
%%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 -
5 0 obj
[...]
A short time solution would be to simple remove the second link from the GUI when a password protected share is created. Doing so will be a proper defense against user errors, but it will still leave unprotected links in various logs. A thorough fix has to eliminate the unprotected links completely, access to the file must only be given to requests containing the share password.
2025-03-27 Identified the vulnerability in version 2.32.02025-04-11 Contacted the project2025-04-29 Vulnerability disclosed to the project2025-06-25 Uploaded advisories to the project's GitHub repository2025-06-25 CVE ID assigned by GitHub2025-06-29 Mitigation of user error released in version 2.34.22025-06-29 Issue #5239 opened to track a more thorough fix of the feature