GHSA-7789-65HX-F26W: Username Enumeration via Authentication Timing Side-Channel in FileBrowser Quantum

FileBrowser Quantum provides web-based file management capabilities, exposing an authentication endpoint at /api/auth/login. Versions prior to v1.3.2-beta contain a timing side-channel vulnerability, tracked under CWE-208. The flaw allows unauthenticated remote attackers to perform username enumeration by analyzing the response time of authentication requests.

The discrepancy arises from the application's handling of database lookups and subsequent password hashing operations. The application optimizes the login flow by exiting early when a requested user does not exist in the backend database. This structural design inadvertently exposes the internal state of the application to external observers.

Username enumeration serves as a critical reconnaissance phase for attackers targeting authentication systems. By confirming which usernames are valid, an attacker maps the active accounts on the platform. This information directly enables targeted credential-based attacks against the exposed service.

The vulnerability stems from an optimization in the authentication logic that prematurely aborts the login process when a user lookup fails. When an authentication request is received, the application first queries the database for the provided username. If the query returns no user, the application immediately returns an error, resulting in a server response time of approximately 1 to 4 milliseconds.

Conversely, if the user exists, the application proceeds to verify the provided password using the computationally expensive bcrypt hashing algorithm. The bcrypt comparison function introduces an intentional and heavy processing delay, typically taking 40 to 50 milliseconds to complete depending on the configured cost factor.

This measurable difference in execution time creates a reliable oracle for attackers. The application effectively telegraphs the result of the database query through the execution time of the HTTP request. An attacker simply measures the delta between the short execution path and the long execution path to determine the existence of a specific username.

In the vulnerable implementation, the server evaluated the database lookup error immediately upon return from the user store. The CheckPwd function, which wraps the bcrypt comparison, was bypassed entirely for non-existent users. This short-circuit evaluation directly caused the timing discrepancy.

The patch, introduced in commit af08800667b874620edc6f44c3e2e64fec7abd85, normalizes the execution time across all authentication attempts. The developers implemented a constant-time authentication flow by introducing a pre-calculated dummy hash (utils.InvalidPasswordHash) during application startup.

user, getErr := userStore.Get(username)
var passwordHash string
if getErr != nil {
    passwordHash = utils.InvalidPasswordHash
} else {
    passwordHash = user.Password
}
 
err = utils.CheckPwd(password, passwordHash)
 
if getErr != nil {
    return nil, fmt.Errorf("unable to get user: %v", getErr)
}

This updated logic ensures that the utils.CheckPwd function executes during every login attempt, regardless of whether the user exists. The error from a failed user lookup is deferred until after the password hash comparison completes, masking the existence of the user behind a uniform response latency.

Exploiting this vulnerability requires the attacker to submit multiple login requests utilizing a dictionary of candidate usernames. The attacker records the precise response latency for each HTTP POST request submitted to the /api/auth/login endpoint. By applying statistical analysis to the collected response times, the attacker groups the results into two distinct clusters: fast responses and slow responses.

The reliability of this attack depends heavily on network conditions. In a low-latency environment, such as a local area network or a direct peering connection, the 40-millisecond delta is consistently measurable. Exploitation over the public internet introduces network jitter, which complicates the timing measurements.

To overcome network jitter, attackers average the response times over multiple requests for the same username. By establishing a baseline latency for known-invalid usernames, the attacker sets a threshold. Any username that consistently yields a response time significantly above this threshold is marked as valid.

Successful exploitation provides the attacker with a verified list of valid usernames registered on the target FileBrowser Quantum instance. While this does not grant direct access to the system or result in remote code execution, it represents a high-value reconnaissance capability. This information exposure directly facilitates subsequent attack chains.

Attackers utilize the enumerated username list to conduct targeted brute-force attacks and credential stuffing campaigns. By eliminating invalid usernames from their target list, attackers significantly reduce the volume of requests required for a successful intrusion.

This reduction in traffic volume also decreases the likelihood of triggering account lockout mechanisms or rate-limiting security controls. Organizations rely on the ambiguity of login errors to slow down attackers; stripping away this ambiguity weakens the overall authentication posture.

Administrators must upgrade FileBrowser Quantum to version v1.3.2-beta or later to remediate this vulnerability. The updated version implements a constant-time authentication flow, neutralizing the timing side-channel. No additional configuration changes are required to activate this protection once the software is updated.

Organizations unable to patch immediately should implement mitigation controls at the network perimeter. Web Application Firewalls (WAF) can be configured to strictly rate-limit requests to the /api/auth/login endpoint from individual IP addresses. This slows down the enumeration process, making large-scale dictionary attacks unfeasible.

Security teams should monitor authentication logs for anomalous patterns. An unusually high volume of failed login attempts spanning diverse usernames, originating from a single source, strongly indicates active enumeration activity. Automated detection platforms can perform statistical analysis on response times for known-bad versus potentially-good usernames to proactively identify vulnerable endpoints.