--- id: "CVE-2026-126609" page: "https://infrastack.ai/live/CVE-2026-126609" kind: "vulnerability" aliases: ["CVE-2026-126609"] title: "hMailServer: certificate file name lookup on Windows lets attackers spoof trust" severity: "high" cvss: 7.5 epss: null exploited: false status: "open" category: "package" products: [{"name": "hMailServer", "fixed": ["6.3.8"], "affected": ">= 6.2.25, <= 6.3.7 (Windows)", "ecosystem": "vendor"}] ecosystems: [] tags: ["hmailserver", "package", "postgresql", "self-hosted", "tls", "windows"] not_affected_if: ["ascii-file-name", "bundled-mariadb-connector", "default-config", "linux", "no-root-cert-file"] published_at: "2026-11-11T09:17:12+00:00" first_seen_at: "2026-11-11T09:26:47+00:00" updated_at: "2026-11-11T09:31:11+00:00" sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-126609", "first_seen_at": "2026-11-11T09:26:47+00:00"}, {"source": "analyst", "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/114", "first_seen_at": "2026-11-11T09:31:11+00:00", "cites": ["https://gitlab.com/hmailserver/hmailserver/-/work_items/114", "https://www.progressiverobot.com/hmailserver/Hmail-server/6.3.8/readme.txt"]}] exploit_sources: [] --- # hMailServer: certificate file name lookup on Windows lets attackers spoof trust Link for people: https://infrastack.ai/live/CVE-2026-126609 (this .md is for agents) hMailServer on Windows, when connecting to PostgreSQL with certificate verification and a named root certificate file, can be made to trust an attacker's certificate authority because the file name is interpreted in two different encodings. A local attacker who can create a file at the alternate name and who can intercept or stand in for the database connection can read and modify traffic to the database, including the database password. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - vendor:hMailServer affected >= 6.2.25, <= 6.3.7 (Windows) fixed 6.3.8 ## How to check - Windows only. Check the installed hMailServer version: 6.2.25 through 6.3.7 is affected; 6.3.8 is the fix. Linux builds are not affected. - In hMailServer.ini [Database], check for PostgreSQLSslRootCert, or TlsMode=verify-full with TlsCaFile and neither PostgreSQL key set (6.3.4+). Also check the sslmode: require, verify-ca or verify-full (from PostgreSQLSslMode, TlsMode, or PGSSLMODE in the service environment). - Exposed only if the file name has non-ASCII characters whose code-page bytes also read as valid UTF-8 (for example é written as the bytes C3 A9 on code page 1252). An ASCII-only path is not exposed. - Also check if you run MySQL/MariaDB (6.3.4 to 6.3.7) with an Oracle libmysql.dll in place of the bundled MariaDB Connector/C and a TlsCaFile name of that kind. The bundled Connector/C is not affected. ## Fix Upgrade to hMailServer 6.3.8 (released 2 November 2026). It refuses, with error HM7534, a TlsCaFile or PostgreSQLSslRootCert whose name the client cannot be handed as written, so give the file and its folders ASCII-only names before upgrading. Workaround until then: use an ASCII-only path for the root certificate file. ## Timeline - 2026-11-11T09:26:47+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-126609 - 2026-11-11T09:31:11+00:00 analyst https://gitlab.com/hmailserver/hmailserver/-/work_items/114 — Primary: hMailServer work item 114 (confidential-until-release text, via NVD ref) and 6.3.8 release notes. Fix 6.3.8. No exploitation or PoC found; not searched on social, low-profile. Mitigation: ASCII path (derived from advisory). ## Documents - [advisory] hMailServer work item 114: database TLS root certificate name read two ways on Windows https://gitlab.com/hmailserver/hmailserver/-/work_items/114 - [fix] hMailServer 6.3.8 release notes https://www.progressiverobot.com/hmailserver/Hmail-server/6.3.8/readme.txt ## From the sources 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. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_