GHSA-cm2r-rg7r-p7gg CVE-2025-52997 GO-2025-3792
File Browser vulnerable to insecure password handling
- Severity
- 5.9 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.54%
- Chance of exploitation in the next 30 days. Higher than 45.45% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-1392 Use of Default Credentials
- CWE-307 Improper Restriction of Excessive Authentication Attempts
- CWE-521 Weak Password Requirements
- Fix
2.34.1- Upgrade github.com/filebrowser/filebrowser/v2 to this version or later
Description
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:
- 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
secretor even ones with only single digit like1. - New instances are set up with a default password of
adminfor 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. - 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:
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:
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-27Identified the vulnerability in version 2.32.02025-04-11Contacted the project2025-04-29Vulnerability disclosed to the project2025-06-25Uploaded advisories to the project's GitHub repository2025-06-26CVE ID assigned by GitHub2025-06-29Fix 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
- NIST Special Publication 800-63B. Digital Identity Guidelines. Passwords
- Pwned Passwords
- Common Credentials
- CWE-307: Improper Restriction of Excessive Authentication Attempts
- CWE-521: Weak Password Requirements
- CWE-1392: Use of Default Credentials
- Original Advisory
Credits
- Mathias Tausig (SBA Research)
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/filebrowser/filebrowser | <= 1.11.0 |
No fix yet |
| github.com/filebrowser/filebrowser | all versions |
No fix yet |
| github.com/filebrowser/filebrowser/v2 | < 2.34.1 |
2.34.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/filebrowser/filebrowser/v2 Go → 2.34.1
- go
go get github.com/filebrowser/filebrowser/v2@v2.34.1 && go mod tidy
Severity breakdown
CVSS 3.1 5.9
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-1392: Use of Default Credentials
The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.
How to prevent it
- Requirements: Prohibit use of default, hard-coded, or other values that do not vary for each installation of the product - especially for separate organizations.
- Architecture and Design: Force the administrator to change the credential upon installation.
- Installation, Operation: The product administrator could change the defaults upon installation or during operation.
CWE-307: Improper Restriction of Excessive Authentication Attempts
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
How to prevent it
- Architecture and Design: Common protection mechanisms include: Disconnecting the user after a small number of failed attempts Implementing a timeout Locking out a targeted account Requiring a computational task on the user's part.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]
CWE-521: Weak Password Requirements
The product does not require that users should have strong passwords.
How to prevent it
- Architecture and Design: A product's design should require adherance to an appropriate password policy. Specific password requirements depend strongly on contextual factors, but it is recommended to contain the following attributes: Enforcement of a minimum and maximum length Restrictions against password reuse Restrictions against using common passwords Restrictions against using contextual string in the password (e.g., user id, app name) Depending on the threat model, the password policy may include several additional attributes. Complex passwords requiring mixed character sets (alpha, numeric, special, mixed case) Increasing the range of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. Unfortunately, a complex password may be difficult to memorize, encouraging a user to select a short password or to incorrectly manage the password (write it down). Another disadvantage of this approach is that it often does not result in a significant increases in overal password complexity due to people's predictable usage of various symbols. Large Minimum Length (encouraging passphrases instead of passwords) Increasing the number of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long un-predictable passwords. Randomly Chosen Secrets Generating a password for the user can help make sure that length and complexity requirements are met, and can result in secure passwords being used. A disadvantage of this approach is that the resulting password or passpharse may be too difficult to memorize, encouraging them to be written down. See NIST 800-63B [REF-1053] for further information on password requirements.
- Architecture and Design: Consider a second authentication factor beyond the password, which prevents the password from being a single point of failure. See CWE-308 for further information.
- Implementation: Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.
- Implementation: Previously, "password expiration" was widely advocated as a defense-in-depth approach to minimize the risk of weak passwords, and it has become a common practice. Password expiration requires a password to be changed within a fixed time window (such as every 90 days). However, this approach has significant limitations in the current threat landscape, and its utility has been reduced in light of the adoption of related protection mechanisms (such as password complexity and computational effort), along with the recognition that regular password changes often caused users to generate more predictable passwords. As a result, this is now a Discouraged Common Practice [REF-1488] [REF-1489], especially as the sole factor in protecting passwords. It is still strongly encouraged to force password changes in case of evidence of compromise, but this is not the same as a forced "expiration" on an arbitrary time frame.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-833g-cqhp-h72j File Browser: Share API exposes the password hash and bypass token | Low | Also affects github.com/filebrowser/filebrowser |
| GHSA-83xp-526h-j3ww File Browser: Archive builder turns backslash filenames into path traversal (zip-slip) | Medium | Also affects github.com/filebrowser/filebrowser |
| GHSA-7rc3-g7h6-22m7 File Browser: Colliding username normalization gives two users the same home directory | High | Also affects github.com/filebrowser/filebrowser |
| GHSA-8wc8-hf36-mjh9 File Browser: ScopedFs follows a dangling symlink on write, letting a scoped user create files outside their scope | Medium | Also affects github.com/filebrowser/filebrowser |
| GHSA-fmm7-x4gx-8jhr File Browser: Out-of-scope file deletion by a Create-only scoped user via symlink-following RemoveAll in upload failure-cleanup | High | Also affects github.com/filebrowser/filebrowser |
| GHSA-xqp3-jq6g-x3qm File Browser: Authentication Bypass via Proxy Auth Header Forgery | Critical | Also affects github.com/filebrowser/filebrowser |
| GHSA-m93h-4hw7-5qcm File Browser: Command Injection via Authentication Hook Shell Substitution (Pre-Authentication RCE) | Critical | Also affects github.com/filebrowser/filebrowser |
| GHSA-8c9q-7855-wfxq File Browser has a Command Execution Allowlist Bypass via Shell Metacharacter Injection | High | Also affects github.com/filebrowser/filebrowser |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor