IT SBIT Services
Schneeberger
DEEN
CVE tracker

hMailServer: Improper certificate validation for database TLS connections

CVE-2026-126610High 7.4

← All vulnerabilities

Summary

hMailServer 6.3.4 to 6.3.7 does not pass the configured TlsCaFile to the MySQL or MariaDB client when the file name contains non-ASCII characters, while certificate verification stays enabled. An attacker who can intercept or stand in for the database connection can read and modify traffic between hMailServer and its database, and can obtain the database password in some configurations. The issue only applies when TlsMode is set to verify-full, which is not the default (prefer checks no certificate).

Affected

  • hMailServer 6.3.4 to 6.3.7 with MySQL or MariaDB, TlsMode=verify-full and a TlsCaFile name containing non-ASCII characters
  • MariaDB Connector/C 3.4.2 to 3.4.10 as database client (CONC-853), and 3.4.1 to 3.4.9 in combination with CVE-2026-107819
  • Local connections (127.0.0.1, ::1, Unix socket, named pipe) with Connector/C 3.4.1 and later are affected when no CA file is set

Fixed in

  • hMailServer 6.3.8: refuses a TlsCaFile name it cannot pass to the client (HM7534) instead of silently dropping it
  • MariaDB Connector/C 3.4.11 or later on Linux (fixes CVE-2026-107819 and CONC-853)

Workaround

  • Use a TlsCaFile path containing only ASCII characters that points to the CA which issued the database server certificate
  • Do not rely on the 6.3.7 release notes, which named a TlsCaFile as mitigation for CVE-2026-107819; that did not hold for non-ASCII names

Exploitation

No evidence of exploitation in the wild found. No public proof of concept found in the sources checked.

Our recommendation

  • Upgrade hMailServer to 6.3.8 and, on Linux, MariaDB Connector/C to 3.4.11 or later
  • Until the upgrade, use an ASCII-only TlsCaFile path
  • Check whether TlsMode=verify-full is used and whether the database connection runs over a shared network
  • Restrict database access to the mail server host and monitor for TLS errors or unexpected connections
  • After upgrading, expect HM7534 errors for non-ASCII CA file names and rename those files

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 11 Nov 2026, 10:27.

Original description (NVD)

Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database and TlsMode=verify-full, does not hand the database client the CA file that TlsCaFile names when the file's name contains a character outside ASCII on Linux, or above U+00FF on Windows, which allows an attacker who can intercept the connection to the database server to read and modify the traffic between hMailServer and its database, by presenting, with MariaDB Connector/C 3.4.2 to 3.4.10 as the client, a certificate from any authority, its own included, for any name, and otherwise a certificate for the database server's name issued by any certificate authority in the system's trust store. The server converted the name for the client with the C runtime's conversion in the C locale, which gives an empty string for such a name, and then set no CA file at all, without an error, while certificate verification stayed on, so the client - MariaDB Connector/C, bundled on Windows and the distribution's on Linux - verified the certificate of a database server over the network against the system's trust store instead of the configured CA; Connector/C 3.4.2 to 3.4.10 (bundled on Windows in 6.3.4 to 6.3.6) went further and, with no CA file, took a certificate within its dates whose issuer it could not find, for any name, with neither its chain nor its name checked and no password proof, when the server offered first a sign-in method that hashes the password, which an attacker in the middle chooses (MariaDB's CONC-853, fixed in Connector/C 3.4.11), and Connector/C 3.4 accepted from a MariaDB 11.4 or later server a certificate the store did not vouch for when that server proved it held the account's password; on a connection it treats as local (127.0.0.1, ::1, a Unix socket, a named pipe, and localhost on Windows), Connector/C 3.4.1 and later checked neither the certificate's issuer nor its name, so that a local attacker able to stand in for the database server could present any certificate within its dates of its own making. The settings line of hmailserver --check-database still named the configured file, and the application log said the certificate had been checked. With MariaDB Connector/C 3.4.1 to 3.4.9 as the client - bundled on Windows in 6.3.4 to 6.3.6, and the client of Linux distributions that have not patched it - the missing CA file also met the precondition of CVE-2026-107819, so that a certificate issued for any other name by a trusted authority was enough to obtain the database password. On Linux the file was found only when the server ran on glibc under a locale whose character set holds the name's characters (a UTF-8 locale, or a legacy 8-bit one the system has, in whose bytes the file is then named); with no locale, LC_ALL=C or a locale the system lacks, and on Alpine (musl), the connection failed instead. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate.

NVD references (2)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.