{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-126614", "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", "state": "PUBLISHED", "assignerShortName": "GitLab", "dateReserved": "2026-11-11T08:04:49.376Z", "datePublished": "2026-11-11T08:32:32.127Z", "dateUpdated": "2026-11-11T08:32:32.127Z"}, "containers": {"cna": {"title": "Improper Restriction of Excessive Authentication Attempts in hMailServer", "descriptions": [{"lang": "en", "value": "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."}], "affected": [{"vendor": "Progressive Robot Ltd", "product": "hMailServer", "repo": "https://gitlab.com/hmailserver/hmailserver", "versions": [{"version": "6.3.3", "status": "affected", "lessThanOrEqual": "6.3.7", "versionType": "semver"}], "defaultStatus": "unaffected"}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "CWE-307: Improper Restriction of Excessive Authentication Attempts", "cweId": "CWE-307", "type": "CWE"}]}], "references": [{"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/105"}, {"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}], "cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "LOW", "integrityImpact": "NONE", "availabilityImpact": "NONE", "baseScore": 5.3, "baseSeverity": "MEDIUM"}}], "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'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."}], "credits": [{"lang": "en", "value": "Found by the hMailServer project (Progressive Robot Ltd)", "type": "finder"}], "providerMetadata": {"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", "shortName": "GitLab", "dateUpdated": "2026-11-11T08:32:32.127Z"}}}}

{}

{}

{}

{}