CVE-2026-104704 in hMailServer
Summary
by MITRE • 10/08/2026
Progressive Robot hMailServer 6.0.0 through 6.3.5 does not enforce TLS for outbound SMTP delivery to a mail exchanger whose DNSSEC-validated TLSA records contain no DANE-EE (usage 3) record, contrary to RFC 7672 section 2.2. The server used only DANE-EE records and treated a validated TLSA record set consisting of DANE-TA (usage 2) or otherwise unusable records as if no records were published, so delivery to such a host fell back to opportunistic TLS. An attacker with an active position on the network path between the server and the recipient's mail exchanger can suppress or break the STARTTLS negotiation and cause messages to be delivered in cleartext, where they can be read and modified.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.5 represents a critical misconfiguration of DNS-based Authentication of Named Entities implementation, specifically regarding the handling of TLSA records during outbound SMTP delivery. According to RFC 7672 section 2.2, mail servers are expected to enforce strict DANE policies when secure transport is required for message integrity and confidentiality. However, this software exhibits a flaw where it fails to properly distinguish between different types of DNSSEC-validated TLSA records. The server incorrectly assumes that only DANE-EE (usage type 3) records constitute valid evidence for enforcing Transport Layer Security. Consequently, if the target mail exchanger publishes only DANE-TA (usage type 2) or other unusable record types, hMailServer treats this validated set as if no DNSSEC data exists at all. This logical error leads to an unintended fallback mechanism where the server defaults to opportunistic TLS rather than rejecting the connection or enforcing a secure channel based on the available cryptographic evidence.
From a technical perspective, the core issue lies in the validation logic within the SMTP client component of hMailServer. When initiating a connection to a remote mail exchanger, the software queries for DNSSEC-validated TLSA records. Upon receiving these records, it performs an incomplete check that ignores DANE-TA records which are valid under certain deployment scenarios or legacy configurations. By disregarding these valid cryptographic assertions, the server incorrectly concludes that no secure transport policy is in place. This results in the initiation of a STARTTLS negotiation without the necessary strictness required for high-security environments. If the network path allows an attacker to interfere with this negotiation, such as by dropping TLS handshake packets or sending premature failure responses, the connection will degrade to plain text SMTP. This behavior directly contradicts the security expectations set forth by RFC 7672 and exposes sensitive email communications to interception.
The operational impact of this vulnerability is severe for organizations relying on hMailServer for secure email transmission. An attacker positioned actively within the network path between the sending server and the recipient's mail exchanger can exploit this flaw through a man-in-the-middle attack. By suppressing or breaking the STARTTLS negotiation, the attacker forces the communication to fall back to cleartext SMTP. In this state, all message content, including headers and body text, is transmitted without encryption. This allows for both passive eavesdropping and active modification of messages. Sensitive information such as personal data, corporate secrets, or authentication credentials contained within emails can be read by unauthorized parties. Furthermore, the ability to modify messages in transit undermines the integrity of communications, potentially leading to phishing attacks, fraud, or corruption of business logic dependent on email inputs.
This vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-319 Cleartext Transmission of Sensitive Information within the Common Weakness Enumeration framework. It also maps to MITRE ATT&CK techniques related to Network Sniffing (T1040) and Man-in-the-Middle Attacks (T1557), as it facilitates unauthorized interception and alteration of network traffic. To mitigate this risk, administrators should immediately update hMailServer to a version that correctly implements RFC 7672 requirements by recognizing DANE-TA records appropriately or enforcing strict TLS policies regardless of specific record types if the organization's security policy demands it. Additionally, organizations can implement SMTP STARTTLS enforcement at the network perimeter using firewalls or dedicated email gateways that inspect and enforce encryption standards independently of the mail server's internal logic. Regular auditing of DNSSEC configurations and ensuring that both sending and receiving parties adhere to consistent DANE policies are essential steps to prevent such fallback scenarios.