Skip to main content

hMailServer CVE-2026-114472

| EUVDEUVD-2026-107315 LOW
Insufficient Resource Pool (CWE-410)
2026-10-21 GitLab GHSA-m7x4-4w88-7g5p
3.7
CVSS 3.1 · Vendor: GitLab
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Connect to ACME responder on port 80
  2. Exploit
    Hold idle sockets through CA validation
  3. Execution
    Certificate renewal/issuance times out
  4. Impact
    Certificate expires, clients refuse TLS

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V2 - Validation and Business Logic Insufficient resource pool
Exploitation Conditions

Exploitation requires that the target hMailServer is configured to obtain or renew TLS certificates via ACME, so that the HTTP-01 challenge responder is actively listening on port 80 and reachable by the attacker; no authentication is needed to connect. Exploitation is strongly limited by timing: the attacker's idle connections must coincide with an in-progress certificate authority validation to starve the single-connection worker, and impact only materializes if interference is sustained across renewal cycles until the certificate expires - the mail service continues on its existing certificate until then. In the fixed 6.3.7 the responder serves up to 64 simultaneous connections, so an attacker must hold 64 idle connections open at once during validation rather than a handful. Deployments not using ACME, or with the port-80 responder firewalled from untrusted networks, are not exposed.

Impact

This is a low-severity, availability-only issue and should be treated as low priority despite being remote and unauthenticated. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L, base 3.7) is internally consistent with the description: network-reachable and unauthenticated (PR:N), but high complexity (AC:H) because exploitation must coincide with an in-progress ACME certificate validation, and only a limited availability impact (A:L, C:N/I:N). No EPSS score, KEV listing, or POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the realistic threat is a motivated attacker deliberately timing idle connections to a specific target rather than mass exploitation. The impact is also indirect and delayed - the mail service keeps running on its current certificate and only fails once the certificate actually expires after sustained interference across renewals, so there is no immediate outage. The one data-quality concern is the input tag 'Information Disclosure', which contradicts both CWE-410 (Insufficient Resource Pool / resource exhaustion) and the CVSS C:N/I:N/A:L impact - there is no confidentiality dimension to this flaw.

Exploit ScenarioDerived

An attacker who knows a target hMailServer renews TLS certificates via ACME opens TCP connections to the HTTP-01 challenge responder on port 80 and sends nothing, holding the single-connection worker for the full five-second timeout each time. By keeping the responder occupied throughout a certificate authority validation window, the CA's own request is not answered in time and the renewal fails; repeated across renewal cycles the certificate eventually expires and clients refuse the server's TLS. No public exploit code is identified at time of analysis, and attack complexity is high because the attacker must sustain this across validation windows.

Monitor Track and reassess. Why: LOW severity (CVSS 0.1-3.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 21, 2026

Denial of TLS certificate issuance and renewal in Progressive Robot hMailServer 6.0.0 through 6.3.6 stems from the ACME HTTP-01 challenge responder handling only one connection at a time. A remote unauthenticated attacker can open idle connections during a certificate authority validation so the single worker waits up to five seconds per connection and the CA request times out, causing validation failure; sustained interference across renewals can let the certificate expire and make clients reject the server's TLS, although mail service continues on the current certificate until then. The issue is low-severity and availability-only, with no public exploit identified at time of analysis, and is fixed in 6.3.7, which serves up to 64 concurrent connections.

RemediationAI

Upgrade to hMailServer 6.3.7 or later, which increases the ACME HTTP-01 responder to 64 concurrent connections and closes excess connections; see https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7 and https://gitlab.com/hmailserver/hmailserver/-/work_items/97. If immediate upgrade is not possible, avoid exposing the port-80 responder broadly: restrict inbound port 80 to the certificate authority's validation traffic where feasible, use DNS-01 validation instead of HTTP-01 if supported by the deployment to remove reliance on the port-80 responder, and monitor for many idle connections during renewal windows. Each workaround has trade-offs: narrow firewall rules can block validation if CA source ranges change, DNS-01 requires DNS provider API credentials and configuration, and monitoring only detects rather than prevents the starvation.

Affected VersionsENISA

hMailServer 6.0.0 ≤6.3.6

Affected Packages

euvd hmailserver no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is CWE-410 (Insufficient Resource Pool) in hMailServer's ACME HTTP-01 responder. ACME HTTP-01 requires the certificate authority to fetch a token over HTTP from port 80 on the server being validated; hMailServer 6.0.0 through 6.3.6 accepted one socket at a time, waited up to five seconds for a request, answered it, and only then accepted the next connection. Because the pool is effectively one worker, idle connections consume the only slot and can crowd out the CA's validation request. The CPE cpe:2.3:a:progressive_robot_ltd:hmailserver:*:*:*:*:*:*:*:* is version-unbounded, but the described affected range is 6.0.0 through 6.3.6; 6.3.7 raises concurrency to 64 and closes connections beyond that, so an attacker must hold 64 idle connections open simultaneously during validation rather than a handful one after another. The CVSS vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L reflects remote unauthenticated access with high attack complexity and availability-only impact.

Know when Hmailserver gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitLab) PRIMARY 3.7 LOW
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
vuln.today AI 3.7 LOW

Network-reachable and unauthenticated (PR:N), but AC:H because the attack must coincide with a CA validation window, and only limited, delayed availability impact (A:L, C:N/I:N).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (GitLab).

CVSS VectorVendor: GitLab

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
Low
niche open-source Windows mail server, small production footprint
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity LOW
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
LOW severity (CVSS 0.1-3.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact· derived
Low

Priority Score

18
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +18
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0
CVE-2026-100741 CRITICAL POC
9.8 Sep 27

Arbitrary JScript execution in Progressive Robot Ltd's hMailServer 6.0.0 through 6.3.3 on Windows lets an unauthenticate

CVE-2026-114489 HIGH
8.1 Oct 21

Cross-tenant configuration takeover in hMailServer 6.0.0 through 6.3.6 lets an authenticated user holding only a domain-

CVE-2026-103647 HIGH
8.0 Oct 08

Cross-site scripting in Progressive Robot hMailServer 6.3.2 through 6.3.5 can let a remote, unauthenticated attacker exe

CVE-2026-114490 HIGH
7.8 Oct 21

Incorrect authorization in the COM administration API of hMailServer 6.3.4 through 6.3.6 lets a credential holding the s

CVE-2026-107571 HIGH
7.8 Oct 19

Local privilege escalation in Progressive Robot hMailServer 6.0.0 through 6.3.6 allows any authenticated, non-administra

CVE-2026-107573 HIGH
7.8 Oct 08

Incorrect default permissions in the Windows installer for Progressive Robot hMailServer 6.0.0 through 6.3.5 let any loc

CVE-2026-103010 HIGH
7.8 Oct 08

Heap-based buffer overflow in hMailServer 6.0.0 through 6.3.3 on Windows lets a local interactive user - with no hMailSe

CVE-2026-104660 HIGH
7.8 Oct 08

Local privilege escalation in hMailServer 6.0.0 through 6.3.5 on Windows allows an authenticated local user-one with an

CVE-2026-104658 HIGH
7.8 Oct 08

Local privilege escalation in Progressive Robot hMailServer 6.3.4 and 6.3.5 on Linux allows an attacker who already has

CVE-2026-107569 HIGH
7.5 Oct 19

Denial of service in hMailServer 6.0.0 through 6.3.6 lets a remote unauthenticated sender exhaust the mail queue and dis

CVE-2026-114476 HIGH
7.5 Oct 21

Privilege escalation in Progressive Robot hMailServer 6.3.4 through 6.3.6 allows an authenticated holder of the manage_r

CVE-2026-107567 HIGH
7.5 Oct 19

DKIM signing in Progressive Robot hMailServer 6.0.0 through 6.3.6 can be induced to sign attacker-authored mail with the

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy