CyberSecBulletin
CVE-2026-126609NVD status: Deferred

hMailServer: Improper Certificate Validation

Published Updated By the CyberSecBulletin desk

CVE-2026-126609 is a high-severity improper certificate validation vulnerability in hMailServer from Progressive Robot, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an attacker with a low-privileged account, without any action from a user. Affected hMailServer versions: 6.2.25 through 6.3.7. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.17% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Check which version of hMailServer you run against the affected versions below, and install the vendor's latest release.

Affected products and versions

VendorProductAffected versionsFixed in
Progressive RobothMailServer6.2.25 through 6.3.7Not stated

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
HighSuccess depends on conditions outside the attacker's control.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA (gitlab.com).

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

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How developers prevent this class of flaw

  • Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

More Improper Certificate Validation vulnerabilities (CWE-295)

Timeline

  1. CVE record published.
  2. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in hMailServer

All hMailServer vulnerabilities

Recent Improper Certificate Validation vulnerabilities

Spotted an error? Tell us.