hMailServer: Improper certificate validation through file name handling on Windows
Summary
On Windows, hMailServer 6.0.0-B1 through 6.3.7 passes the names of its TLS files to OpenSSL in a form that OpenSSL may read as UTF-8, so it can open a different file than the one configured. This affects listener certificates and keys, DH parameters, client-certificate CA files, the object store CA file and ACME files. The flaw is not exploitable in the default configuration. A local user who can create a file or folder under the other name can, where client-certificate login, the object store CA or ACME is enabled, get a rogue CA accepted for network logins or message interception, obtain ACME private keys, or stop TLS ports from starting. The Linux builds are not affected.
Affected
- hMailServer Windows builds 6.0.0-B1 to 6.3.7
- Linux builds are not affected
- Default configuration is not affected
Fixed in
- Upgrade to hMailServer 6.3.8
Workaround
- Until the upgrade, use only ASCII names for TLS, CA, key, DH and ACME files and for their folders
- Disable client-certificate authentication on ports if not needed
- Disable the object store and ACME features if not needed
- Restrict who can create files or folders in ProgramData locations next to administrator-managed TLS files
Exploitation
Unknown. No public exploit or in-the-wild exploitation was found at the time of research.
Our recommendation
- Upgrade all Windows hMailServer instances to 6.3.8
- Before upgrading, rename non-ASCII TLS-related files and folders to ASCII names and test TLS port startup, because refused files can stop a TLS port from starting
- Check whether client-certificate login, the object store CA or ACME is enabled, and disable unused features until the upgrade
- Restrict file and folder creation in ProgramData locations used for TLS files
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- hMailServer 6.3.8 release page gitlab.com
- Work item 115: TLS files on Windows gitlab.com
- OffSeq: CVE-2026-126621 radar.offseq.com
- hMailServer 6.3.8 on GitHub github.com
- hMailServer 6.3.8 downloads (Progressive Robot) www.progressiverobot.com
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 11 Nov 2026, 10:24.
Original description (NVD)
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.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.