Medium · CVSS 5.3CVE-2026-126614

Improper Restriction of Excessive Authentication Attempts in hMailServerCVE-2026-126614

Answer in brief

CVE-2026-126614 records a Medium severity (CVSS 5.3) vulnerability in Improper Restriction of Excessive Authentication Attempts in hMailServer. The current sources do not mark it as known exploited. The current feed maps Progressive Robot Ltd/hMailServer (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Nov 11, 2026Updated Nov 11, 2026Source checked Nov 11, 2026First seen by HOL Nov 11, 2026Material review Nov 11, 2026

Upstream Advisory

Key facts

Risk: Medium · CVSS 5.3
Exploitation: Not marked as known exploited
Affected software: 1 mapped package or product
Fix availability: Not reported

Why this deserves its current priority

CVSS is 5.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Progressive Robot Ltd/hMailServer (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Progressive Robot Ltd/hMailServergeneric	>=6.3.3 <=6.3.7	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Progressive Robot Ltd/hMailServer.
Review the reported fix. Source-reported solution: 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's 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's 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's ports below the server: an AutoBanCommand of the administrator's own, which is run for every ban the server writes, can block the address on the listener's 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's ports to its port line blocks there, by the jail's own count (five matching lines within ten minutes as packaged; maxretry = 3 and findtime = 30m match the auto-ban's 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' failures then ban the proxy's own address at the mail listeners unless that address is in AutoBanNeverBan.

Evidence timeline and material changes

Published upstream
Nov 11, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Nov 11, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Nov 11, 2026

Sources and claim methodology

Upstream source description

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.

Quoted source text, attributed separately from HOL analysis.

Package

Affected range

Fixed version

Progressive Robot Ltd/hMailServergeneric

>=6.3.3 <=6.3.7

Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Progressive Robot Ltd/hMailServer.

Review the reported fix. Source-reported solution: 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's 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's 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's ports below the server: an AutoBanCommand of the administrator's own, which is run for every ban the server writes, can block the address on the listener's 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's ports to its port line blocks there, by the jail's own count (five matching lines within ten minutes as packaged; maxretry = 3 and findtime = 30m match the auto-ban's 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' failures then ban the proxy's own address at the mail listeners unless that address is in AutoBanNeverBan.

Sources and claim methodology

Upstream source description

Quoted source text, attributed separately from HOL analysis.

Improper Restriction of Excessive Authentication Attempts in hMailServerCVE-2026-126614

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

Related CVEs

Improper Restriction of Excessive Authentication Attempts in hMailServerCVE-2026-126614

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

Related CVEs