Progressive Robot hMailServer: Improper certificate validation in database TLS
Summary
On Windows, hMailServer can be made to trust the wrong certificate authority when a root certificate file is configured for a PostgreSQL database connection, or for TlsCaFile with an Oracle MySQL client library. The root certificate file name contains non-ASCII characters that also read as valid UTF-8, so the database client checks the server certificate against a different file. A local attacker who can create that file and can intercept or impersonate the database server can read and modify traffic between hMailServer and its database, including the database password. The configuration is not the default.
Affected
- Progressive Robot hMailServer 6.2.25 through 6.3.7 on Windows with a PostgreSQL database, sslmode require, verify-ca or verify-full, and a root certificate file set in PostgreSQLSslRootCert (from 6.2.25) or TlsCaFile with TlsMode=verify-full (from 6.3.4)
- hMailServer 6.3.4 through 6.3.7 on Windows with TlsCaFile and an Oracle MySQL client library in place of the bundled MariaDB Connector/C
- Not affected: default configuration (no root certificate file named), bundled MariaDB Connector/C, Linux builds
Fixed in
- Fixed in hMailServer 6.3.8
Workaround
- Name the root certificate file by a path that contains only ASCII characters, for example C:\ProgramData\hMailServer\database-ca.pem, in PostgreSQLSslRootCert or TlsCaFile
- If a non-ASCII name must stay, make sure no other user can create the file or folder that the UTF-8 reading of the name points to
- Restrict write access to the folders that hold the certificate file, including ProgramData and any restricted folder directly under the system drive root
Exploitation
- Not known to be exploited according to OffSeq and VulDB
- No public proof of concept or exploit found during research
- The vendor reported the issue; exploitation requires local access plus a position to intercept or impersonate the database server
Our recommendation
- Identify hMailServer instances on Windows that use PostgreSQL or TlsCaFile and check hMailServer.ini for PostgreSQLSslRootCert or TlsCaFile
- Upgrade to hMailServer 6.3.8; before upgrading, rename any non-ASCII paths as the release notes describe
- If upgrading is not possible, use an ASCII-only path for the root certificate file or restrict write access to its folders
- Review which users hold local accounts on the server and limit them to what is needed
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- hMailServer 6.3.8 release notes (GitLab) gitlab.com
- Vendor issue #114: Database TLS on Windows gitlab.com
- hMailServer 6.3.8 download page (Progressive Robot) www.progressiverobot.com
- VulDB entry CVE-2026-126609 vuldb.com
- CVE-2026-126609 record (threatint) cve.threatint.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:26.
Original description (NVD)
Progressive Robot hMailServer 6.2.25 through 6.3.7 on Windows, with a PostgreSQL database, the connection's sslmode require, verify-ca or verify-full, and a root certificate file named by PostgreSQLSslRootCert (from 6.2.25) or, with TlsMode=verify-full and neither PostgreSQL key set, by TlsCaFile (from 6.3.4), hands the file's name to libpq as bytes in the system's ANSI code page (up to 6.3.5 as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF), and libpq looks for the file by those bytes and then hands the same bytes to OpenSSL, whose file opening on Windows reads a name as UTF-8 first and opens the file at that reading when one is there. When every byte of the name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9 on code page 1252, which are U+00E9 in UTF-8 - the database server's certificate was checked against the file at that other name whenever one was there, which allows a local attacker who can create that file but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, or beside a folder directly under the system drive's root whose permissions the administrator restricted, and who can intercept the connection to the database server or stand in for it, to have hMailServer trust a certificate authority of the attacker's own and read and modify the traffic between hMailServer and its database, the database password included; the file alone, holding no authority that issued the database server's certificate, stops hMailServer from connecting to its database. The same applies in 6.3.4 through 6.3.7 to TlsCaFile when an Oracle MySQL client library has been put in place of the bundled MariaDB Connector/C, since that client opens the file through OpenSSL in the same way; the bundled MariaDB Connector/C opens the file in the code page and is not affected, and neither are the Linux builds. The configuration is not the default: by default no root certificate file is named.
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.