--- id: "CVE-2026-126621" page: "https://infrastack.ai/live/CVE-2026-126621" kind: "vulnerability" aliases: ["CVE-2026-126621"] title: "hMailServer on Windows: TLS file names let local users swap certificates" severity: "high" cvss: 7.5 epss: null exploited: false status: "open" category: "package" products: [{"name": "hMailServer", "fixed": ["6.3.8"], "affected": ">= 6.0.0-B1, <= 6.3.7 (Windows)", "ecosystem": "vendor"}] ecosystems: [] tags: ["email", "hmailserver", "package", "tls", "windows"] not_affected_if: ["ascii-file-names", "client-certs-off", "default-config", "linux"] published_at: "2026-11-11T09:17:14+00:00" first_seen_at: "2026-11-11T09:26:48+00:00" updated_at: "2026-11-11T09:31:17+00:00" sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-126621", "first_seen_at": "2026-11-11T09:26:48+00:00"}, {"source": "analyst", "url": "https://www.hmailserver.co.uk/topic/28278/hmailserver-6.3.8-security-fixes-for-every-earlier-version-read-before-upgrading-and-a-helm-chart-that-starts-a-server", "first_seen_at": "2026-11-11T09:31:17+00:00", "cites": ["https://www.hmailserver.co.uk/topic/28278/hmailserver-6.3.8-security-fixes-for-every-earlier-version-read-before-upgrading-and-a-helm-chart-that-starts-a-server", "https://www.progressiverobot.com/hmailserver/Hmail-server/6.3.8/readme.txt"]}] exploit_sources: [] --- # hMailServer on Windows: TLS file names let local users swap certificates Link for people: https://infrastack.ai/live/CVE-2026-126621 (this .md is for agents) hMailServer on Windows passes non-ASCII TLS file names to OpenSSL in a way that lets a local attacker substitute their own certificate files. The attacker can then sign in as any mailbox, intercept object store traffic, or receive ACME-issued private keys. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - vendor:hMailServer affected >= 6.0.0-B1, <= 6.3.7 (Windows) fixed 6.3.8 ## How to check - Windows only. Check the installed hMailServer version: affected is 6.0.0-B1 through 6.3.7; 6.3.8 is fixed. Linux builds are not affected. - Look in the hMailServer settings for TLS certificate, key, chain or dh2048.pem paths, client-certificate CA file (client certificates on a port, from 6.2.19, login by certificate from 6.2.25), MessageStoreObjectCaFile (from 6.3.4), or the ACME directory, containing any non-ASCII character. - Exposed only if a file name has non-ASCII characters, the feature is on, and a non-admin local user can create files or folders beside it (e.g. under ProgramData). ## Fix Upgrade to hMailServer 6.3.8 (released 2 November 2026). On Windows it reads the configured file or refuses a name it cannot hand to OpenSSL as written (error HM7536). Before upgrading, give TLS certificate/key files, dh2048.pem, client-certificate CA file, MessageStoreObjectCaFile and AcmeCertificateDirectory files, and the folders above them, ASCII names, or the port or feature using them will not start. Until then, use ASCII-only paths and restrict write access to the folders beside those files. ## Timeline - 2026-11-11T09:26:48+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-126621 - 2026-11-11T09:31:17+00:00 analyst https://www.hmailserver.co.uk/topic/28278/hmailserver-6.3.8-security-fixes-for-every-earlier-version-read-before-upgrading-and-a-helm-chart-that-starts-a-server — Fix 6.3.8 taken from maintainer release notes/announcement: work item 115 'On Windows the files the server hands to OpenSSL by name are read from the file configured, or refused' matches the CVE description; the notes do not print the CVE id (CVE requested), so the link is by description. Not exploited, no PoC found. Tier B, single pass. ## Documents - [advisory] hMailServer 6.3.8: security fixes (maintainer announcement) https://www.hmailserver.co.uk/topic/28278/hmailserver-6.3.8-security-fixes-for-every-earlier-version-read-before-upgrading-and-a-helm-chart-that-starts-a-server - [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.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. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_