{"affected":[{"defaultStatus":"unaffected","product":"hMailServer","source":"CNA: GitLab","vendor":"Progressive Robot Ltd","versions":[{"lessThanOrEqual":"6.3.7","status":"affected","version":"6.3.4","versionType":"semver"}]}],"cveId":"CVE-2026-126611","cwes":["CWE-295"],"description":"Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database, TlsMode=verify-full and no TlsCaFile, does not verify the database server's certificate's issuer or name when the connection is one that MariaDB Connector/C treats as local - Server= set to 127.0.0.1, ::1 or localhost (on Linux a Unix socket), to . on Windows (a named pipe), or to a comma-separated list of servers that holds such an element - which allows a local attacker who can stand in for the database server, for example by listening on its port while it is stopped or restarting, to receive the database sign-in, the password included, and to read and modify the traffic between hMailServer and its database. hMailServer applied verify-full by turning the client's certificate verification on without a CA file, but MariaDB Connector/C 3.4.1 and later, on a connection they treat as local and with no CA file, accept any certificate within its validity period that is self-signed or sent with its own root, for any name (Connector/C 3.4.2 to 3.4.10 also one whose issuer they cannot find), so the client accepted the certificate an impostor made, asked no proof of the password and allowed a switch to an authentication method that sends the password unhashed, while hmailserver --check-database said the certificate had been checked against the system's trust store and the application log that it had been checked. The Windows builds bundle Connector/C 3.4.9 (6.3.4 to 6.3.6) and 3.4.11 (6.3.7); on Linux the distribution's client is used, and Connector/C 3.3 and 3.4.0 and Oracle's MySQL client are not affected. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate.","epss":null,"exploits":[],"kev":null,"metrics":[{"score":7,"severity":"high","source":"CNA: GitLab","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}],"modifiedAt":1794385832132,"publishedAt":1794385832132,"references":[{"source":"CNA: GitLab","tags":[],"url":"https://gitlab.com/hmailserver/hmailserver/-/work_items/113"},{"source":"CNA: GitLab","tags":[],"url":"https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"}],"remediation":[{"kind":"fix","source":"CNA: GitLab","text":"Upgrade to hMailServer 6.3.8, which reads Server= as MariaDB Connector/C does and refuses TlsMode=verify-full with no TlsCaFile before connecting, with HM7535 in the error log, on a connection the client treats as local or a Server= list that holds one, and which says, on such a connection with a TlsCaFile, that the certificate's issuer was checked and not its name. Until then, set TlsCaFile to a file holding only the CA that issues the database server's certificate, at a path in ASCII alone; the client then checks the certificate's issuer on such a connection, though not its name. On these versions the --check-database settings line and the application log say the certificate was checked either way, so they do not show the difference."}],"revision":"803c5b076efa987818af3a2f33a2b30aa733641546eb873e91cb32b521398a0a","sources":[{"modifiedAt":1794385832132,"name":"CNA: GitLab","retrievedAt":1794388110788,"url":"https://www.cve.org/CVERecord?id=CVE-2026-126611"}],"ssvc":null,"status":"published","title":"Improper Certificate Validation in hMailServer","updatedAt":1794388110788}