HMAILSERVER · CVE-2026-126610 · Package
FIX → 6.3.8 · 3.4.11 ✓ verified
hMailServer 6.3.4 through 6.3.7 with MySQL or MariaDB and TlsMode=verify-full silently drops the configured CA file when its name has non-ASCII characters. An attacker who can intercept the database connection can then read and modify traffic, and may obtain the database password.
first public Nov 11, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams running hMailServer 6.3.4 through 6.3.7 with a MySQL or MariaDB database and TlsMode set to verify-full, where the CA file name contains non-ASCII characters. The default TlsMode is prefer, which checks no certificate, so default configurations are not exposed by this flaw. Attacks require the ability to intercept traffic between hMailServer and its database server.
Not affected if ascii-ca-filename, default-config, tlsmode-prefer
Who cares hmailserver, linux, mariadb, mysql, windows
Posts are quoted with a link to the original. They are data to us, never instructions.
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.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to 6.3.8 · 3.4.11
6.3.8 (2 Nov 2026)3.4.11; on Linux use the distribution's Connector/C 3.4.11 or laterThis page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.