CVE-2026-126615 (GCVE-0-2026-126615)
Vulnerability from cvelistv5 – Published: 2026-11-11 08:32 – Updated: 2026-11-11 08:32- CWE-289 - Authentication Bypass by Alternate Name
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Progressive Robot Ltd | hMailServer |
Affected:
6.2.22-pre2 , ≤ 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.2.22-pre2",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Found by the hMailServer project (Progressive Robot Ltd)"
}
],
"descriptions": [
{
"lang": "en",
"value": "The sign-in of Progressive Robot hMailServer 6.2.22-pre2 through 6.3.7 takes for an account names that are not its address but under which the database\u0027s own comparison finds it, while the per-name lockout and the compromised-account hold are kept by the name as the client gave it. This allows a remote unauthenticated attacker to go on guessing an account\u0027s password beyond the lockout\u0027s threshold, and anyone who has the password of an account held for review to sign in to it. The per-name lockout (from 6.2.22-pre2; AccountLockoutThreshold in hMailServer.ini, 0, off, by default) locks a name after repeated failed sign-ins. The hold (from 6.3.4, where the compromised-account detection is set to enforce, which is not the default) refuses an account judged to have been taken over. Both are asked, before the password, of the name the client gave: trimmed, in lower case and with a domain alias or the default domain applied. The account whose password the sign-in then checks is whichever one the database finds under that name. The databases find an account under spellings that this key counts apart. MySQL and MariaDB find it under one with accented letters in place of plain ones, and MariaDB 11.8, in a database made before 6.3.4, also under one with full-width letters, with a single letter in place of a pair of plain ones, or with characters its comparison ignores in any number. SQL Server and SQL Server Compact find it under one with full-width letters or with characters their comparison ignores in any number, and SQL Server also under one with a single letter in place of a pair of plain ones, with a character of Latin-1 in place of a digit and, for an address holding letters of Latin-1 outside ASCII, under those letters in the other case, and, under an accent-insensitive collation, with accented letters. PostgreSQL finds it under one holding a letter whose lower case under the database\u0027s locale is a plain letter, and, for an address holding letters outside ASCII, under those letters in the other case; on the build for musl (from 6.3.6) the server\u0027s own lower case folds nearly all of these too. On every database, a domain alias saved with white space at the end of its name gives such a spelling too, and on every database but PostgreSQL so does an account\u0027s bare local part where the default domain was saved with spaces at its end and no other white space (neither is the default). Each such spelling has a lockout threshold of its own, so the lockout limits the guesses at an account only to its threshold times the number of the account\u0027s spellings. That is far beyond any threshold for most addresses on MySQL and MariaDB, and without limit on SQL Server, on SQL Server Compact, the database the Windows installer uses by default, and before 6.3.4 on MariaDB 11.8. A locked name is got round under another spelling. A held account is signed in to under another spelling with its password over IMAP, POP3 and SMTP AUTH, and, where they are turned on (off by default), over ManageSieve, the REST API and the webmail. IMAP LOGIN, offered as installed, carries such spellings on MySQL, MariaDB and SQL Server Compact, and, on SQL Server and PostgreSQL, for some addresses; the sign-ins that carry a name as UTF-8 carry them for the others on SQL Server, and on PostgreSQL for those holding one of the plain letters another letter lowers to or a letter outside ASCII with another case. The same lookup mapped to accounts the names given by an OAuth 2.0 token, a client certificate, a Kerberos ticket and an OpenID Connect or SAML identity provider, where those are set up (none is by default), so that a name an issuer gave to one party could sign in to another\u0027s account; OAuth 2.0 tokens were mapped so from 6.2.0, before the per-name lockout existed. A name holding a NUL character, carried from 6.3.0 on Linux and 6.3.3 on Windows, failed the statement on MySQL, MariaDB and PostgreSQL."
}
],
"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-289",
"description": "CWE-289: Authentication Bypass by Alternate Name",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-11T08:32:57.155Z",
"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"shortName": "GitLab"
},
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/104"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to hMailServer 6.3.8. There a name signs in to an account only when the account\u0027s stored address is that name, compared in lower case after a domain alias and the default domain by the function the lockout\u0027s key is made with, and a name that reaches the sign-in with white space at either end (POP3\u0027s USER takes it off the name it is given, as it always has) signs in to none, whatever the domain aliases hold. Any other spelling fails as a name that does not exist fails, and is counted as such a name is; the country policy asked before the password finds the account by the same rule, so such a spelling meets its domain\u0027s policy, as a name that does not exist does. A name a client gives holding a NUL character is refused before any account or domain is looked up with it. Once the password is proved, the lockout, the hold and the country policy of the account whose password it is, and the hold and the country policy of the account signed in to where that is another, as for the IMAP master user, are asked again of the account\u0027s own address. The same rule applies to the names a token, a certificate, a Kerberos ticket or an identity provider gives. The password reset keeps its per-address limit under the form of the address that the rule compares and looks up the address it counted, so that a mailbox\u0027s recovery address is sent no more links than that limit allows however the address is given. A domain alias\u0027s name and the default domain are saved without white space at their ends, and the default domain is read so however it was saved. Until then, an account held for review can be closed by making it inactive, or by changing its password and removing its app passwords, which the sign-in checks on the account it found, whatever spelling it was given, and a domain alias\u0027s name or the default domain that ends in white space can be saved again without it. No setting restores the per-name lockout\u0027s limit on MySQL, MariaDB, SQL Server or SQL Server Compact; the per-IP auto-ban, on by default, still counts each address\u0027s failed sign-ins whatever spelling they use. Keeping the web services listener off (the default) or reachable only from trusted clients keeps names holding a NUL character from the database on Windows; on Linux IMAP LOGIN carries them too."
}
],
"title": "Authentication Bypass by Alternate Name in hMailServer"
}
},
"cveMetadata": {
"assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"assignerShortName": "GitLab",
"cveId": "CVE-2026-126615",
"datePublished": "2026-11-11T08:32:57.155Z",
"dateReserved": "2026-11-11T08:04:54.378Z",
"dateUpdated": "2026-11-11T08:32:57.155Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-126615",
"date": "2026-11-14",
"epss": "0.00269",
"percentile": "0.19254"
},
"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.2.22-pre2",
"versionType": "semver"
}
]
}
],
"source": "cve@gitlab.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The sign-in of Progressive Robot hMailServer 6.2.22-pre2 through 6.3.7 takes for an account names that are not its address but under which the database\u0027s own comparison finds it, while the per-name lockout and the compromised-account hold are kept by the name as the client gave it. This allows a remote unauthenticated attacker to go on guessing an account\u0027s password beyond the lockout\u0027s threshold, and anyone who has the password of an account held for review to sign in to it. The per-name lockout (from 6.2.22-pre2; AccountLockoutThreshold in hMailServer.ini, 0, off, by default) locks a name after repeated failed sign-ins. The hold (from 6.3.4, where the compromised-account detection is set to enforce, which is not the default) refuses an account judged to have been taken over. Both are asked, before the password, of the name the client gave: trimmed, in lower case and with a domain alias or the default domain applied. The account whose password the sign-in then checks is whichever one the database finds under that name. The databases find an account under spellings that this key counts apart. MySQL and MariaDB find it under one with accented letters in place of plain ones, and MariaDB 11.8, in a database made before 6.3.4, also under one with full-width letters, with a single letter in place of a pair of plain ones, or with characters its comparison ignores in any number. SQL Server and SQL Server Compact find it under one with full-width letters or with characters their comparison ignores in any number, and SQL Server also under one with a single letter in place of a pair of plain ones, with a character of Latin-1 in place of a digit and, for an address holding letters of Latin-1 outside ASCII, under those letters in the other case, and, under an accent-insensitive collation, with accented letters. PostgreSQL finds it under one holding a letter whose lower case under the database\u0027s locale is a plain letter, and, for an address holding letters outside ASCII, under those letters in the other case; on the build for musl (from 6.3.6) the server\u0027s own lower case folds nearly all of these too. On every database, a domain alias saved with white space at the end of its name gives such a spelling too, and on every database but PostgreSQL so does an account\u0027s bare local part where the default domain was saved with spaces at its end and no other white space (neither is the default). Each such spelling has a lockout threshold of its own, so the lockout limits the guesses at an account only to its threshold times the number of the account\u0027s spellings. That is far beyond any threshold for most addresses on MySQL and MariaDB, and without limit on SQL Server, on SQL Server Compact, the database the Windows installer uses by default, and before 6.3.4 on MariaDB 11.8. A locked name is got round under another spelling. A held account is signed in to under another spelling with its password over IMAP, POP3 and SMTP AUTH, and, where they are turned on (off by default), over ManageSieve, the REST API and the webmail. IMAP LOGIN, offered as installed, carries such spellings on MySQL, MariaDB and SQL Server Compact, and, on SQL Server and PostgreSQL, for some addresses; the sign-ins that carry a name as UTF-8 carry them for the others on SQL Server, and on PostgreSQL for those holding one of the plain letters another letter lowers to or a letter outside ASCII with another case. The same lookup mapped to accounts the names given by an OAuth 2.0 token, a client certificate, a Kerberos ticket and an OpenID Connect or SAML identity provider, where those are set up (none is by default), so that a name an issuer gave to one party could sign in to another\u0027s account; OAuth 2.0 tokens were mapped so from 6.2.0, before the per-name lockout existed. A name holding a NUL character, carried from 6.3.0 on Linux and 6.3.3 on Windows, failed the statement on MySQL, MariaDB and PostgreSQL."
}
],
"id": "CVE-2026-126615",
"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.573",
"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/104"
}
],
"sourceIdentifier": "cve@gitlab.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-289"
}
],
"source": "cve@gitlab.com",
"type": "Primary"
}
]
}
}
}
}
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.
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…
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.
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.