CVE-2026-107585: Allocation of Resources Without Limits or Throttling in hMailServer
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.6 - Configuration
Keep password sign-in available for administrators until the upgrade is applied.
hMailServer password sign-in = enabled - Compensating control
At a reverse proxy, limit the rate of /portal/oidc/start, /portal/saml/start, and /api/v1/passkeys/challenge per client.
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service condition?
Progressive Robot hMailServer 6.3.4 and 6.3.5 are affected where the REST API exposes routes used to start OpenID Connect or SAML single sign-on, or to issue passkey sign-in challenges. Users relying on those sign-in methods can be prevented from completing authentication while the attack continues.
What does an attacker need to exploit it?
The attacker only needs network access to the unauthenticated REST API routes that initiate single sign-on or passkey authentication. No account, credentials, or user interaction is required.
How does the attack disrupt legitimate sign-ins?
The pending sign-in tables are bounded and evict the oldest entry when full, regardless of who created it. By repeatedly starting sign-ins, an attacker can remove pending state for legitimate users before their browsers complete the authentication flow.
What can be done if upgrading is not immediately possible?
The provided data does not identify a workaround. Reducing or restricting unauthenticated access to the affected REST API sign-in initiation routes may limit exposure, but no specific mitigation is stated.
Is a fixed release available?
The references include the hMailServer v6.3.6 release, indicating that a release following the affected 6.3.4 and 6.3.5 versions is available. The provided data does not state the precise remediation details in that release.