Insufficient Resource Pool in hMailServer
Summary
| CVE | CVE-2026-114472 |
|---|---|
| State | PUBLISHED |
| Assigner | GitLab |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-10-21 16:17:34 UTC |
| Updated | 2026-10-21 16:17:34 UTC |
| Description | 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. |
Risk And Classification
Primary CVSS: v3.1 3.7 LOW from [email protected]
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Problem Types: CWE-410 | CWE-410 CWE-410: Insufficient Resource Pool
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 3.7 | LOW | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 3.1 | CNA | CVSS | 3.7 | LOW | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Progressive Robot Ltd | HMailServer | affected 6.0.0 6.3.6 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7 | [email protected] | gitlab.com | |
| gitlab.com/hmailserver/hmailserver/-/work_items/97 | [email protected] | gitlab.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Found in the hMailServer project's own security review (Progressive Robot Ltd) (en)
Additional Advisory Data
Solutions
CNA: Upgrade to hMailServer 6.3.7, whose ACME challenge responder serves each accepted connection on its own short-lived handler, up to 64 at once, instead of one at a time, so that one idle connection no longer holds up the others; it closes a connection past those 64, so that a client that keeps 64 idle connections open throughout a validation still has the certificate authority's connection closed. Until then, and with 6.3.7 where that remaining case matters, where ACME is in use, restrict who may reach the challenge port during a renewal if the surrounding network allows it, or obtain certificates with an external ACME client (for example a DNS-01 client) so that this responder does not run, and monitor certificate expiry so that a starved renewal is noticed before the certificate lapses.