Improper Certificate Validation in hMailServer
Summary
| CVE | CVE-2026-126621 |
|---|---|
| State | PUBLISHED |
| Assigner | GitLab |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-11-11 09:17:14 UTC |
| Updated | 2026-11-11 09:17:14 UTC |
| Description | Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 on Windows hands OpenSSL the names of its own TLS files - the listeners' certificates, chains, private keys and Diffie-Hellman parameters, a port's client-certificate CA file (from 6.2.19), the object store's CA file (from 6.3.4) and the ACME client's keys and certificates - as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF, and OpenSSL's file opening on Windows reads a name as UTF-8 first and opens the file at that reading when it is there, or creates it there when its folder is. When every byte of a configured name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9, which are U+00E9 in UTF-8 - the server used the file at that other name whenever one was there, which allows a local attacker who can create that file or its folder but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, to have a port that logs on by client certificate (from 6.2.25) accept certificates from a certificate authority of the attacker's own and so sign in over the network as any mailbox without its password; to have the server trust such an authority for its object store and, intercepting that connection, read and modify the messages it stores; to receive the private keys the ACME client writes, the key of a certificate issued for the server's names among them; or to keep TLS ports from starting. The configuration is not the default: by default these files have names in ASCII, client certificates are off on every port, and the object store and ACME are off. The Linux builds are not affected. |
Risk And Classification
Primary CVSS: v3.1 7.5 HIGH from [email protected]
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Problem Types: CWE-295 | CWE-295 CWE-295: Improper Certificate Validation
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 7.5 | HIGH | CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | CNA | CVSS | 7.5 | HIGH | CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Progressive Robot Ltd | HMailServer | affected 6.0.0-B1 6.3.7 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| gitlab.com/hmailserver/hmailserver/-/work_items/115 | [email protected] | gitlab.com | |
| gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 | [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.8, which on Windows hands OpenSSL the name of each of these files in the code page and refuses, with HM7536 in the error log, a name with a character the code page does not have or whose bytes outside ASCII also read as UTF-8, so that nothing is read from or written to a refused file: a listener whose certificate or key file is refused does not start, a refused client-certificate CA file verifies no certificate, the object store's refused CA file allows no request, and the ACME client orders no certificate. Until then, name every TLS file, the ACME directory and the program and data folders by paths in ASCII alone, which read as the same name in the code page and in UTF-8 and which every affected version hands over unchanged; where a name outside ASCII must stay, keep each of its characters at or below U+00FF and one the system code page writes as its Latin-1 byte (on code page 1252, U+00A0 to U+00FF; none under a UTF-8 code page) - change any other name to ASCII - and make sure no one else can create the file or folder that the name's UTF-8 reading names.