# CVE-2026-126611: Improper Certificate Validation in hMailServer

Status: published. Published: 2026-11-11. Updated: 2026-11-11.

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.

## Remediation

- fix: 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. (source: CNA: GitLab)

## Affected products and versions

- Progressive Robot Ltd / hMailServer: ≥ 6.3.4; ≤ 6.3.7 (affected, semver). Source: CNA: GitLab

## Severity and prioritization

- CVSS 3.1: 7 (high); CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H; source: CNA: GitLab

- CISA KEV: No listing in collected sources

- EPSS: Not available

- SSVC: Not available

- Weaknesses: CWE-295

## Exploit evidence

No exploit evidence in collected sources. This is not proof of no exploitation.

## References

- https://gitlab.com/hmailserver/hmailserver/-/work_items/113 (CNA: GitLab)

- https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 (CNA: GitLab)

## Provenance

- CNA: GitLab: https://www.cve.org/CVERecord?id=CVE-2026-126611; retrieved 2026-11-11; source updated 2026-11-11

Revision: 803c5b076efa987818af3a2f33a2b30aa733641546eb873e91cb32b521398a0a

Canonical: https://y2.dev/cve/CVE-2026-126611

## Agent and API access

Public CVE pages, Markdown, and JSON are free to read without an account or API key.

- Public catalog: https://y2.dev/cve/index.json. Follow nextCursor with the same search, filters, sort, and limit (1–100). A null cursor marks the end.

- WebMCP: search_cve_disclosures, get_cve_disclosure, get_cve_page_markdown, get_y2_cve_access. Available in compatible browsers.

- Cyber API: https://api.y2.dev/api/v2/cyber/cves and https://api.y2.dev/api/v2/cyber/cves/{cveId}.

- Y2 Pro or Elite: create a workspace API key with the intel:cyber scope and send Authorization: Bearer <Y2_API_KEY>. Setup: https://y2.dev/docs/api/create-key.

- x402: Pay per request without an account or API key. Omit Authorization, read the HTTP 402 PAYMENT-REQUIRED challenge, validate its current requirements, and retry with PAYMENT-SIGNATURE through an authorized payment client. These browser tools never make payments. Guide: https://y2.dev/docs/api/x402.

- OpenAPI: https://y2.dev/api/openapi.yaml. Agent access metadata: https://y2.dev/cve/agent.json.

Collected public records only. Check source status for coverage and freshness.