CVE-2026-107584: Not Failing Securely ('Failing Open') in hMailServer
Progressive Robot hMailServer 6.0.0 through 6.3.5 fails open when applying DANE (RFC 7672) to outbound SMTP delivery. The server's validating DNSSEC resolver treated a TLSA or MX lookup that did not complete (no answer, SERVFAIL, a malformed reply), an answer without the requested records and without an NSEC/NSEC3 proof of their absence, and an answer whose records carried no applicable RRSIG as if the recipient domain were unsigned, and from 6.2.19 it also delivered to mail exchangers taken from an unvalidated MX lookup that the DNSSEC-validated MX record set did not name. An attacker who can drop, forge or strip DNS answers on the path to the server's resolver, at the resolver, or between the resolver and the recipient domain's name servers, and who holds an active position on the SMTP path, can thereby disable DANE for a DNSSEC-signed recipient domain and cause messages to be delivered in cleartext or to a host of the attacker's choosing with an arbitrary certificate, where they can be read and modified.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.6 - Configuration
For each recipient domain whose mail must be protected, configure an SMTP route with connection security set to STARTTLS (required) and enable remote certificate verification with VerifyRemoteSslCertificate=1.
hMailServer SMTP route Connection security and VerifyRemoteSslCertificate = STARTTLS (required); VerifyRemoteSslCertificate=1 - Compensating control
Use a trusted path to the server's DNS resolver, such as a validating resolver on the same host.
Event History
Frequently Asked Questions
Which hMailServer installations are affected?
Progressive Robot hMailServer versions 6.0.0 through 6.3.5 are affected.
What attacker capabilities are required for exploitation?
An attacker must be able to drop, forge, or strip DNS responses on a relevant DNS path and also hold an active position on the SMTP path. No authentication or user interaction is required.
What changed for versions starting with 6.2.19?
From 6.2.19, the server could also deliver mail to exchangers obtained from an unvalidated MX lookup when those exchangers were not named by the DNSSEC-validated MX record set.