{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-126611", "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", "state": "PUBLISHED", "assignerShortName": "GitLab", "dateReserved": "2026-11-11T08:04:34.376Z", "datePublished": "2026-11-11T08:30:32.132Z", "dateUpdated": "2026-11-11T08:30:32.132Z"}, "containers": {"cna": {"title": "Improper Certificate Validation in hMailServer", "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."}], "affected": [{"vendor": "Progressive Robot Ltd", "product": "hMailServer", "repo": "https://gitlab.com/hmailserver/hmailserver", "versions": [{"version": "6.3.4", "status": "affected", "lessThanOrEqual": "6.3.7", "versionType": "semver"}], "defaultStatus": "unaffected"}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "CWE-295: Improper Certificate Validation", "cweId": "CWE-295", "type": "CWE"}]}], "references": [{"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/113"}, {"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}], "cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "attackVector": "LOCAL", "attackComplexity": "HIGH", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "baseScore": 7, "baseSeverity": "HIGH"}}], "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."}], "credits": [{"lang": "en", "value": "Found by the hMailServer project (Progressive Robot Ltd)", "type": "finder"}], "providerMetadata": {"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", "shortName": "GitLab", "dateUpdated": "2026-11-11T08:30:32.132Z"}}}}

{}

{"affected": [{"affectedData": [{"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"}]}], "source": "cve@gitlab.com"}], "cveTags": [], "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."}], "id": "CVE-2026-126611", "lastModified": "2026-11-11T09:17:12.973", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.0, "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"}, "exploitabilityScore": 1.0, "impactScore": 5.9, "source": "cve@gitlab.com", "type": "Secondary"}]}, "published": "2026-11-11T09:17:12.973", "references": [{"source": "cve@gitlab.com", "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"}, {"source": "cve@gitlab.com", "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/113"}], "sourceIdentifier": "cve@gitlab.com", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-295"}], "source": "cve@gitlab.com", "type": "Primary"}]}

{}

{}