CVE-2026-114472 in hMailServer
Summary
by MITRE • 10/21/2026
Insufficient resource pool in the ACME HTTP-01 challenge responder of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to cause a certificate issuance or renewal to fail. When the server obtains or renews a TLS certificate over ACME it runs an HTTP-01 challenge responder on port 80 for the certificate authority to read the challenge token; the responder served one connection at a time, accepting a socket, waiting up to five seconds to receive a request, answering it, and only then accepting the next. A client that connected and sent nothing held the single worker for the whole timeout, so enough idle connections during a validation keep the certificate authority's own request from being answered in time and the validation fails. Sustained across a certificate's renewals this leads to the certificate expiring, after which clients refuse the server's TLS; the mail service itself continues on its current certificate until then. No authentication is required to connect to the responder. Version 6.3.7 serves up to 64 connections at once and closes a connection past that, so that where a handful of idle connections, one after another, sufficed before, a client must keep 64 idle connections open at once throughout a validation to have the certificate authority's connection closed.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.6 represents a critical resource exhaustion flaw within the ACME HTTP-01 challenge responder component, specifically classified under CWE-400: Uncontrolled Resource Consumption. This architectural deficiency allows remote unauthenticated attackers to disrupt the automated certificate issuance and renewal processes managed by the Automated Certificate Management Environment protocol. The core technical failure stems from the single-threaded nature of the HTTP-01 challenge responder, which is designed to handle only one connection at a time during the validation phase required for obtaining or renewing TLS certificates via Let's Encrypt or similar certification authorities.
During the ACME workflow, the server must expose an HTTP endpoint on port 80 where the certificate authority can retrieve a specific token proving domain control ownership. The vulnerable implementation accepts a socket connection and waits up to five seconds for an incoming request before responding. If a client establishes this TCP connection but fails to send any data within that timeout window, it effectively monopolizes the single available worker thread. This behavior creates a denial-of-service condition where legitimate requests from the certificate authority are blocked because the server is still waiting on idle connections held by malicious actors. By maintaining multiple such idle connections simultaneously, an attacker can exhaust the limited resource pool of the challenge responder, preventing the CA's validation request from being processed in time and causing the entire certificate issuance or renewal to fail with a timeout error.
The operational impact of this vulnerability extends beyond immediate service disruption during the validation window. Because ACME certificates typically have short lifespans requiring frequent automated renewals, sustained exploitation can lead to a situation where no new valid certificates are issued before existing ones expire. Once a certificate expires, modern mail clients and TLS-aware applications will refuse connections to the server due to trust chain verification failures. This results in a loss of confidentiality and integrity for email communications routed through hMailServer, as users may be unable to send or receive encrypted messages until a valid certificate is restored. Notably, while client connectivity via TLS is broken, the underlying mail service continues to operate using its current expired certificate, creating a confusing state where the server appears online but secure communication channels are effectively severed for compliant clients.
This attack vector aligns with MITRE ATT&CK technique T1496: Resource Hijacking or more specifically aspects of Denial of Service via resource exhaustion, leveraging the lack of concurrency controls in network-facing services. The vulnerability exploits the fundamental assumption that challenge responders will receive timely responses from trusted certificate authorities without interference from unauthenticated third parties. By holding connections open with no payload, attackers bypass authentication mechanisms entirely, making this a low-effort, high-impact attack against any hMailServer instance relying on automated ACME-based TLS management.
Mitigation strategies focus primarily on upgrading to version 6.3.7 or later of Progressive Robot hMailServer, which addresses the root cause by implementing concurrent connection handling capable of serving up to sixty-four connections simultaneously. This architectural change ensures that idle client connections no longer block legitimate certificate authority requests, as the server can process multiple challenges in parallel and enforce limits on open sockets per IP address. For environments unable to immediately patch, administrators should consider deploying a reverse proxy or web application firewall in front of hMailServer's port 80 to manage connection timeouts more aggressively than the native responder allows, thereby preventing idle connections from persisting for the full five-second duration required by the vulnerable implementation. Additionally, monitoring logs for repeated failed ACME challenges can help identify ongoing exploitation attempts and trigger automated responses such as IP blocking before certificate expiration occurs.