Improper Restriction of Excessive Authentication Attempts in hMailServer
Summary
| CVE | CVE-2026-126616 |
|---|---|
| State | PUBLISHED |
| Assigner | GitLab |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-11-11 09:17:13 UTC |
| Updated | 2026-11-11 09:17:13 UTC |
| Description | The auto-ban of Progressive Robot hMailServer 6.2.0 through 6.3.3, with a MySQL or MariaDB database, can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker to go on guessing account passwords from a single address without being banned. The server makes its MySQL tables in MySQL's utf8 character set, which holds no character outside the Basic Multilingual Plane, sends its statements as UTF-8 over a utf8mb4 connection and leaves the database's default strict mode in place. From 6.2.0 it decodes the user name of a SASL PLAIN logon as UTF-8, so the name can hold such a character. When the failed logons counted from one address reach MaxInvalidLogonAttempts (3 by default), the server clears that address's count, saves an IP range named "Auto-ban: " followed by the user name of the logon that reached the limit, and drops the connection. If such a character is in the part of the user name that the range's name keeps (the name is cut to 100 characters), the database refuses the range: no range is saved, the address is not refused, and, its count having already been cleared, it is given the next full set of attempts. An attacker can in this way spend all but the last attempt of each set on password guesses, and make the last under such a name. On Windows, POP3 AUTH PLAIN reaches it on a server as installed, and IMAP AUTHENTICATE PLAIN where IMAP SASL authentication is turned on (off by default); on Windows and on Linux (from 6.3.0), SMTP AUTH PLAIN reaches it where plain-text authentication is allowed (off by default), and ManageSieve and CardDAV where they are turned on (off by default). Each failed save is reported in the server's error log. A database whose strict mode has been turned off stores the character as a question mark and makes the first such ban, but refuses every later ban named after the same user name, or after one holding other such characters in their place, as a duplicate while the first stands, since the server cannot look up a name holding such a character there. |
Risk And Classification
Primary CVSS: v3.1 5.3 MEDIUM from [email protected]
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Problem Types: CWE-307 | CWE-307 CWE-307: Improper Restriction of Excessive Authentication Attempts
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 5.3 | MEDIUM | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | CNA | CVSS | 5.3 | MEDIUM | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Progressive Robot Ltd | HMailServer | affected 6.2.0 6.3.3 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| gitlab.com/hmailserver/hmailserver/-/releases/v6.3.4 | [email protected] | gitlab.com | |
| gitlab.com/hmailserver/hmailserver/-/work_items/103 | [email protected] | gitlab.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Found by the hMailServer project (Progressive Robot Ltd) (en)
Additional Advisory Data
Solutions
CNA: Upgrade to hMailServer 6.3.4 or later, whose database schema 6102 converts every MySQL and MariaDB table to utf8mb4, and which runs only on a database upgraded to its schema; 6.3.8 also fixes a separate way round the auto-ban. Until then, converting the IP range table as that step does (ALTER TABLE hm_securityranges ENGINE=InnoDB, ROW_FORMAT=DYNAMIC, CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci) lets the database store such a name, and setting MaxInvalidLogonAttempts to 1 closes this way round, since every failed logon then reaches the limit by itself, and a guess at an account, made under a name the table can hold, is banned under it.