Description
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.
Published: 2026-11-11
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

Vendor Solution

Upgrade to hMailServer 6.3.8, which on Windows refuses before connecting, with HM7534 in the error log, a root certificate file name whose bytes in the code page outside ASCII also read as UTF-8, for PostgreSQLSslRootCert and TlsCaFile alike and whichever database client is loaded, and hands an Oracle MySQL client the name in UTF-8, which names the same file. Until then, name the root certificate file by a path in ASCII alone, which reads 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, make sure no one else can create the file or folder that the name's UTF-8 reading names.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 11 Nov 2026 08:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Improper Certificate Validation in hMailServer
Weaknesses CWE-295
References
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitLab

Published:

Updated: 2026-11-11T08:30:17.425Z

Reserved: 2026-11-11T08:04:24.373Z

Link: CVE-2026-126609

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-11T09:17:12.687

Modified: 2026-11-11T09:17:12.687

Link: CVE-2026-126609

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

No data.

Weaknesses