{"api_version":"1","generated_at":"2026-11-11T12:12:49+00:00","cve":"CVE-2026-126611","urls":{"html":"https://cve.report/CVE-2026-126611","api":"https://cve.report/api/cve/CVE-2026-126611.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-126611","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-126611"},"summary":{"title":"Improper Certificate Validation in hMailServer","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.","state":"PUBLISHED","assigner":"GitLab","published_at":"2026-11-11 09:17:12","updated_at":"2026-11-11 09:17:12"},"problem_types":["CWE-295","CWE-295 CWE-295: Improper Certificate Validation"],"metrics":[{"version":"3.1","source":"cve@gitlab.com","type":"Secondary","score":"7","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"7","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"attackComplexity":"HIGH","attackVector":"LOCAL","availabilityImpact":"HIGH","baseScore":7,"baseSeverity":"HIGH","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://gitlab.com/hmailserver/hmailserver/-/work_items/113","name":"https://gitlab.com/hmailserver/hmailserver/-/work_items/113","refsource":"cve@gitlab.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8","name":"https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8","refsource":"cve@gitlab.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-126611","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-126611","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Progressive Robot Ltd","product":"hMailServer","version":"affected 6.3.4 6.3.7 semver","platforms":[]}],"timeline":[],"solutions":[{"source":"CNA","title":"","value":"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.","time":"","lang":"en"}],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Found by the hMailServer project (Progressive Robot Ltd)","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"hMailServer","repo":"https://gitlab.com/hmailserver/hmailserver","vendor":"Progressive Robot Ltd","versions":[{"lessThanOrEqual":"6.3.7","status":"affected","version":"6.3.4","versionType":"semver"}]}],"credits":[{"lang":"en","type":"finder","value":"Found by the hMailServer project (Progressive Robot Ltd)"}],"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"LOCAL","availabilityImpact":"HIGH","baseScore":7,"baseSeverity":"HIGH","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-295","description":"CWE-295: Improper Certificate Validation","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-11-11T08:30:32.132Z","orgId":"ceab7361-8a18-47b1-92ba-4d7d25f6715a","shortName":"GitLab"},"references":[{"url":"https://gitlab.com/hmailserver/hmailserver/-/work_items/113"},{"url":"https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"}],"solutions":[{"lang":"en","value":"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."}],"title":"Improper Certificate Validation in hMailServer"}},"cveMetadata":{"assignerOrgId":"ceab7361-8a18-47b1-92ba-4d7d25f6715a","assignerShortName":"GitLab","cveId":"CVE-2026-126611","datePublished":"2026-11-11T08:30:32.132Z","dateReserved":"2026-11-11T08:04:34.376Z","dateUpdated":"2026-11-11T08:30:32.132Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-11 09:17:12","lastModifiedDate":"2026-11-11 09:17:12","problem_types":["CWE-295","CWE-295 CWE-295: Improper Certificate Validation"],"metrics":{"cvssMetricV31":[{"source":"cve@gitlab.com","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"126611","Ordinal":"1","Title":"Improper Certificate Validation in hMailServer","CVE":"CVE-2026-126611","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"126611","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Improper Certificate Validation in hMailServer"}]}}}