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.
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 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.

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.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.
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:36:26.283Z

Reserved: 2026-11-11T08:30:22.140Z

Link: CVE-2026-126621

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-11T09:17:14.277

Modified: 2026-11-11T09:17:14.277

Link: CVE-2026-126621

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

No data.

Weaknesses
  • CWE-295

    Improper Certificate Validation