CVE-2026-85286 in Homebox
Summary
by MITRE • 11/05/2026
HomeBox is a home inventory and organization system. Prior to 0.27.0, the POST /api/v1/users/login endpoint performs password-hash verification only when the submitted username matches an existing account, while unknown usernames return immediately. Although both paths return the same 401 unauthorized response, the processing-time discrepancy allows an unauthenticated remote attacker to distinguish registered email addresses; rate limiting only reduces the number of attempts per window. This issue is fixed in version 0.27.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in HomeBox versions prior to 0.27.0 represents a classic timing side-channel attack vector within an authentication mechanism. The core technical flaw lies in the asynchronous or sequential processing logic of the POST /api/v1/users/login endpoint, which handles password hash verification differently depending on whether the submitted username corresponds to an existing account in the database. When a valid username is provided, the system proceeds to retrieve the stored password hash and performs cryptographic comparison operations, such as PBKDF2, bcrypt, or scrypt, which consume measurable processing time due to their computational intensity. Conversely, when an invalid or non-existent username is submitted, the application bypasses these expensive hashing steps entirely and returns a 401 Unauthorized response immediately after verifying that no user record exists for that identifier.
This discrepancy in response latency creates a distinguishable signal for an unauthenticated remote attacker capable of making precise network timing measurements. Although both valid and invalid login attempts result in the same HTTP status code, the time delta between receiving the response can be statistically analyzed to infer whether the username is registered within the system. This constitutes an account enumeration vulnerability, allowing adversaries to build a list of legitimate user accounts without needing valid credentials. The attack relies on the principle that cryptographic hash verification takes significantly longer than simple database lookups for non-existent records, and even minor network jitter can be mitigated through repeated sampling and statistical averaging by a determined attacker.
The operational impact of this vulnerability is primarily focused on information disclosure and reconnaissance rather than direct system compromise or data exfiltration in the immediate sense. By successfully enumerating valid email addresses associated with HomeBox accounts, an attacker gains valuable intelligence that facilitates subsequent targeted attacks such as credential stuffing, phishing campaigns, or brute-force attempts against known user identities. While rate limiting mechanisms are present to reduce the volume of requests per time window, they do not fundamentally eliminate the timing discrepancy for each individual successful request within the allowed limit. Therefore, while rate limiting raises the cost and difficulty of the attack by slowing down the enumeration process, it does not provide a complete defense against this side-channel analysis if an attacker can afford the necessary number of attempts or operates with sufficient patience to work around throttling constraints.
From a standards perspective, this vulnerability aligns closely with CWE-208, which describes Observable Timing Discrepancy, and falls under the broader category of CWE-641, Improper Restriction of Excessive Authentication Attempts, although the latter is more commonly associated with brute-force prevention rather than enumeration. In terms of MITRE ATT&CK framework mapping, this behavior supports techniques found in Tactic TA0003 (Persistence) or specifically reconnaissance activities such as Account Enumeration via timing differences, often categorized under discovery tactics where attackers gather information about user accounts to plan further exploitation steps. The vulnerability highlights the importance of constant-time comparison algorithms and uniform error handling paths in authentication modules to ensure that all code branches execute in approximately equal time regardless of input validity.
To mitigate this risk effectively, developers must implement a defense-in-depth strategy that addresses both the timing side-channel and the rate limiting aspects. First, the application should be modified so that password hash verification is performed for all login attempts, including those with non-existent usernames. This can be achieved by generating a dummy or random salted hash when no user is found and performing the same cryptographic comparison operation against it as would be done for a valid user. This ensures that the processing time remains constant regardless of whether the username exists in the database. Additionally, robust rate limiting should be implemented not just on a per-window basis but potentially using more sophisticated methods such as exponential backoff or CAPTCHA challenges after a low threshold of failed attempts to further hinder automated enumeration tools. Upgrading to version 0.27.0 resolves this issue by correcting these authentication logic flaws, ensuring that the system no longer leaks user existence information through response timing variations.