CVE-2026-107585 in hMailServer
Summary
by MITRE • 10/08/2026
Uncontrolled eviction in the pending sign-in tables of the REST API in Progressive Robot hMailServer 6.3.4 and 6.3.5 allows a remote unauthenticated attacker to make other users' OpenID Connect, SAML and passkey sign-ins fail. The routes that start a single sign-on and hand out a passkey sign-in challenge are reached without authentication and stored pending state in bounded tables that dropped their oldest entry when full, whoever had started it. An attacker who starts sign-ins a few times a second (about a hundred a second for passkeys) pushes every other user's pending sign-in out of the table before that user's browser returns, denying single sign-on and passkey sign-in for as long as the requests continue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in hMailServer versions 6.3.4 and 6.3.5 represents a critical flaw within the implementation of its REST API authentication mechanisms, specifically affecting OpenID Connect, SAML, and passkey sign-in workflows. This issue stems from an uncontrolled eviction policy applied to the pending state tables that track active single sign-on sessions. The core technical failure lies in how these bounded data structures handle overflow conditions; rather than rejecting new requests or maintaining session integrity through more robust queue management, the system is configured to drop the oldest entry whenever the table reaches capacity. This design choice creates a direct path for resource exhaustion and denial of service against legitimate authentication processes without requiring any prior credentials or network-level access restrictions on the initial handshake endpoints.
From an operational perspective, this flaw allows remote unauthenticated attackers to disrupt user login capabilities by exploiting the race conditions inherent in the session management logic. The routes responsible for initiating single sign-on flows and issuing passkey challenges are accessible without authentication, meaning any actor on the network can interact with them freely. By generating a high volume of these requests at a rate of approximately one hundred per second for passkeys or slightly lower rates for other protocols, an attacker can rapidly fill the pending state tables. Because the system evicts the oldest entries to make room for new ones, legitimate users who have initiated a sign-in process but are still in the middle of their browser-based authentication flow will find their pending requests removed from memory before they can complete the interaction. This results in immediate failure of the login attempt, effectively locking out the user until the attacker ceases the flooding activity or the system state is manually reset.
The impact of this vulnerability extends beyond simple inconvenience; it constitutes a significant availability risk that undermines trust in the authentication infrastructure. Users attempting to access protected resources via federated identity providers will experience repeated failures, leading to potential productivity loss and increased support overhead for administrators. Furthermore, because the attack requires no prior authentication, it is particularly dangerous as it can be executed by any external actor with network connectivity to the hMailServer instance. This aligns closely with CWE-787 Out-of-bounds Write in terms of memory management principles, although more accurately classified under CWE-400 Uncontrolled Resource Consumption or CWE-613 Insufficient Session Expiration due to improper state handling. The attack vector is also consistent with ATT&CK technique T1499 Endpoint Denial of Service, where the adversary aims to degrade system availability by exhausting resources associated with authentication services.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Administrators should immediately upgrade hMailServer to a patched version that addresses this specific flaw in the REST API session handling logic. In environments where upgrading is not instantly feasible, network-level controls such as rate limiting or IP-based access control lists can be implemented at the firewall or reverse proxy layer to restrict the frequency of authentication initiation requests from single sources. Additionally, developers should review the implementation of pending state tables across all authentication modules to ensure that bounded collections do not silently evict active sessions under load. Implementing proper session timeout mechanisms and ensuring that eviction policies account for ongoing user interactions rather than just entry age will prevent similar vulnerabilities in future iterations. Regular security audits focusing on resource management during high-concurrency scenarios are essential to maintain the integrity of authentication services against denial-of-service attacks.