CVE-2026-126614 (GCVE-0-2026-126614)
Vulnerability from cvelistv5 – Published: 2026-11-11 08:32 – Updated: 2026-11-11 08:32
VLAI
EPSS
VEX
Title
Improper Restriction of Excessive Authentication Attempts in hMailServer
Summary
The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 does not apply the server's IP ranges to the connections it accepts, which allows a remote unauthenticated attacker to go on guessing account passwords at the listener's sign-ins after the auto-ban has banned the attacker's address. The listener is off by default (WebServicesHttpPort and WebServicesHttpsPort 0). From 6.3.3 its CardDAV, and from 6.3.4 its CalDAV and its Outlook Autodiscover answer to a request that carries credentials, sign an account in with HTTP Basic over HTTPS. A failed sign-in there counts towards the auto-ban as a failed logon on any other protocol does: when the failures counted from one address reach MaxInvalidLogonAttempts (3 within 30 minutes by default), the server writes an IP range that refuses the address for AutoBanMinutes (60 by default), and the SMTP, POP3, IMAP and ManageSieve listeners refuse it. The web services listener asked no IP range when it accepted a connection (in 6.3.3 nothing, from 6.3.4 the country policy alone), so it went on serving such an address, whether its ban had been earned there or on another protocol, and also an address that an administrator's IP range allowing nothing holds. Each failed sign-in there closed only its own connection, and the next connection was accepted, during the ban and after it. The firewall rule and command the auto-ban can drive (AutoBanFirewall and AutoBanCommand, off by default) are told only the SMTP, POP3 and IMAP ports, so that the firewall rule and the packaged hook did not close the listener's ports, and the fail2ban jail packaged for Linux (off by default) lists only the mail and ManageSieve ports. The only limit left on the guesses at one account there was the per-name lockout (AccountLockoutThreshold in hMailServer.ini, 0, off, by default), which has a separate defect fixed in the same release. The flaw is reached on the listener's HTTPS port: behind a TLS-terminating proxy the listener sees the proxy's address for every client, and a ban never named the client there.
Severity
5.3 (Medium)
CWE
- CWE-307 - Improper Restriction of Excessive Authentication Attempts
Assigner
References
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Progressive Robot Ltd | hMailServer |
Affected:
6.3.3 , ≤ 6.3.7
(semver)
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThanOrEqual": "6.3.7",
"status": "affected",
"version": "6.3.3",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Found by the hMailServer project (Progressive Robot Ltd)"
}
],
"descriptions": [
{
"lang": "en",
"value": "The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 does not apply the server\u0027s IP ranges to the connections it accepts, which allows a remote unauthenticated attacker to go on guessing account passwords at the listener\u0027s sign-ins after the auto-ban has banned the attacker\u0027s address. The listener is off by default (WebServicesHttpPort and WebServicesHttpsPort 0). From 6.3.3 its CardDAV, and from 6.3.4 its CalDAV and its Outlook Autodiscover answer to a request that carries credentials, sign an account in with HTTP Basic over HTTPS. A failed sign-in there counts towards the auto-ban as a failed logon on any other protocol does: when the failures counted from one address reach MaxInvalidLogonAttempts (3 within 30 minutes by default), the server writes an IP range that refuses the address for AutoBanMinutes (60 by default), and the SMTP, POP3, IMAP and ManageSieve listeners refuse it. The web services listener asked no IP range when it accepted a connection (in 6.3.3 nothing, from 6.3.4 the country policy alone), so it went on serving such an address, whether its ban had been earned there or on another protocol, and also an address that an administrator\u0027s IP range allowing nothing holds. Each failed sign-in there closed only its own connection, and the next connection was accepted, during the ban and after it. The firewall rule and command the auto-ban can drive (AutoBanFirewall and AutoBanCommand, off by default) are told only the SMTP, POP3 and IMAP ports, so that the firewall rule and the packaged hook did not close the listener\u0027s ports, and the fail2ban jail packaged for Linux (off by default) lists only the mail and ManageSieve ports. The only limit left on the guesses at one account there was the per-name lockout (AccountLockoutThreshold in hMailServer.ini, 0, off, by default), which has a separate defect fixed in the same release. The flaw is reached on the listener\u0027s HTTPS port: behind a TLS-terminating proxy the listener sees the proxy\u0027s address for every client, and a ban never named the client there."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-307",
"description": "CWE-307: Improper Restriction of Excessive Authentication Attempts",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-11T08:32:32.127Z",
"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"shortName": "GitLab"
},
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/105"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to hMailServer 6.3.8. Its web services listener reads, once for each connection and before the TLS handshake, the IP range that decides for the address, and closes the connection without an answer when that range allows none of SMTP, POP3 and IMAP - every auto-ban, and an administrator\u0027s range that allows nothing - or when the ranges cannot be read; an address no range holds is let in, and loopback and the addresses in WebServicesTrustedProxies are never refused by a range. A connection opened before the ban has at most one guess after it, since every failed sign-in closes its connection. After the upgrade an administrator\u0027s range that allows none of the three also closes this listener - MTA-STS, ACME http-01 when this listener answers it, CalDAV, CardDAV, Autodiscover, autoconfiguration, the Web Key Directory, security.txt, the S/MIME root and CRL and the Apple profiles - to the addresses it holds, and such a refusal by a range that does not expire is named in the application log, once an hour for each address. Until then, keep WebServicesHttpsPort at 0 or reachable from trusted networks only, or block the listener\u0027s ports below the server: an AutoBanCommand of the administrator\u0027s own, which is run for every ban the server writes, can block the address on the listener\u0027s ports as well as on the ports it is told, for as long as the ban lasts; on Linux, turning the packaged fail2ban jail on (it is off as packaged) and adding the listener\u0027s ports to its port line blocks there, by the jail\u0027s own count (five matching lines within ten minutes as packaged; maxretry = 3 and findtime = 30m match the auto-ban\u0027s defaults), an address that goes on failing at the listener, where application logging is on (off by default), since its filter matches the \"Auto-ban: logon failure\" lines these sign-ins write. Turning on the per-name lockout (AccountLockoutThreshold above 0) limits the guesses at each account wherever they come from, within its separate defect. A rate-limiting proxy in front of the listener limits the guessing, but its clients\u0027 failures then ban the proxy\u0027s own address at the mail listeners unless that address is in AutoBanNeverBan."
}
],
"title": "Improper Restriction of Excessive Authentication Attempts in hMailServer"
}
},
"cveMetadata": {
"assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"assignerShortName": "GitLab",
"cveId": "CVE-2026-126614",
"datePublished": "2026-11-11T08:32:32.127Z",
"dateReserved": "2026-11-11T08:04:49.376Z",
"dateUpdated": "2026-11-11T08:32:32.127Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-126614",
"date": "2026-11-14",
"epss": "0.00433",
"percentile": "0.38139"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThanOrEqual": "6.3.7",
"status": "affected",
"version": "6.3.3",
"versionType": "semver"
}
]
}
],
"source": "cve@gitlab.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 does not apply the server\u0027s IP ranges to the connections it accepts, which allows a remote unauthenticated attacker to go on guessing account passwords at the listener\u0027s sign-ins after the auto-ban has banned the attacker\u0027s address. The listener is off by default (WebServicesHttpPort and WebServicesHttpsPort 0). From 6.3.3 its CardDAV, and from 6.3.4 its CalDAV and its Outlook Autodiscover answer to a request that carries credentials, sign an account in with HTTP Basic over HTTPS. A failed sign-in there counts towards the auto-ban as a failed logon on any other protocol does: when the failures counted from one address reach MaxInvalidLogonAttempts (3 within 30 minutes by default), the server writes an IP range that refuses the address for AutoBanMinutes (60 by default), and the SMTP, POP3, IMAP and ManageSieve listeners refuse it. The web services listener asked no IP range when it accepted a connection (in 6.3.3 nothing, from 6.3.4 the country policy alone), so it went on serving such an address, whether its ban had been earned there or on another protocol, and also an address that an administrator\u0027s IP range allowing nothing holds. Each failed sign-in there closed only its own connection, and the next connection was accepted, during the ban and after it. The firewall rule and command the auto-ban can drive (AutoBanFirewall and AutoBanCommand, off by default) are told only the SMTP, POP3 and IMAP ports, so that the firewall rule and the packaged hook did not close the listener\u0027s ports, and the fail2ban jail packaged for Linux (off by default) lists only the mail and ManageSieve ports. The only limit left on the guesses at one account there was the per-name lockout (AccountLockoutThreshold in hMailServer.ini, 0, off, by default), which has a separate defect fixed in the same release. The flaw is reached on the listener\u0027s HTTPS port: behind a TLS-terminating proxy the listener sees the proxy\u0027s address for every client, and a ban never named the client there."
}
],
"id": "CVE-2026-126614",
"lastModified": "2026-11-12T19:05:35.013",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 1.4,
"source": "cve@gitlab.com",
"type": "Secondary"
}
]
},
"published": "2026-11-11T09:17:13.423",
"references": [
{
"source": "cve@gitlab.com",
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"
},
{
"source": "cve@gitlab.com",
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/105"
}
],
"sourceIdentifier": "cve@gitlab.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-307"
}
],
"source": "cve@gitlab.com",
"type": "Primary"
}
]
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.