# CVE-2026-126614: Improper Restriction of Excessive Authentication Attempts in hMailServer

Status: published. Published: 2026-11-11. Updated: 2026-11-11.

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.

## Remediation

- fix: 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. (source: CNA: GitLab)

## Affected products and versions

- Progressive Robot Ltd / hMailServer: ≥ 6.3.3; ≤ 6.3.7 (affected, semver). Source: CNA: GitLab

## Severity and prioritization

- CVSS 3.1: 5.3 (medium); CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N; source: CNA: GitLab

- CISA KEV: No listing in collected sources

- EPSS: Not available

- SSVC: Not available

- Weaknesses: CWE-307

## Exploit evidence

No exploit evidence in collected sources. This is not proof of no exploitation.

## References

- https://gitlab.com/hmailserver/hmailserver/-/work_items/105 (CNA: GitLab)

- https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 (CNA: GitLab)

## Provenance

- CNA: GitLab: https://www.cve.org/CVERecord?id=CVE-2026-126614; retrieved 2026-11-11; source updated 2026-11-11

Revision: ae5d625364dcb6ebde71b6edffe01d34685d49a7d7c43ce2d4bf21261cc2351e

Canonical: https://y2.dev/cve/CVE-2026-126614

## Agent and API access

Public CVE pages, Markdown, and JSON are free to read without an account or API key.

- Public catalog: https://y2.dev/cve/index.json. Follow nextCursor with the same search, filters, sort, and limit (1–100). A null cursor marks the end.

- WebMCP: search_cve_disclosures, get_cve_disclosure, get_cve_page_markdown, get_y2_cve_access. Available in compatible browsers.

- Cyber API: https://api.y2.dev/api/v2/cyber/cves and https://api.y2.dev/api/v2/cyber/cves/{cveId}.

- Y2 Pro or Elite: create a workspace API key with the intel:cyber scope and send Authorization: Bearer <Y2_API_KEY>. Setup: https://y2.dev/docs/api/create-key.

- x402: Pay per request without an account or API key. Omit Authorization, read the HTTP 402 PAYMENT-REQUIRED challenge, validate its current requirements, and retry with PAYMENT-SIGNATURE through an authorized payment client. These browser tools never make payments. Guide: https://y2.dev/docs/api/x402.

- OpenAPI: https://y2.dev/api/openapi.yaml. Agent access metadata: https://y2.dev/cve/agent.json.

Collected public records only. Check source status for coverage and freshness.