CVE-2026-107567 in hMailServer
Summary
by MITRE • 10/19/2026
Use of a less trusted source in the DKIM signing of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write signed with the DKIM key of a domain the server hosts, so that it passes DKIM and DMARC for that domain at other receivers. With DKIM signing enabled for a hosted domain, the server signed every message on its first delivery pass as the domain named in its From header, before local delivery, whatever the message's origin and without checking that its sender had authenticated. A sender anywhere could therefore send the server, as ordinary inbound mail, a message whose From is any address at such a domain, and the server signed it with that domain's key. Every copy the server then sent on to an address outside carried a valid signature aligned with the forged From, whatever the domain's DMARC policy: an account's forward, a mail rule's forward or copy, a Sieve redirect, an alias or distribution list with an outside member, the mirror copy, a managed-list or journal copy, or a message released from quarantine. A signed copy can also be re-sent to other recipients while the domain's key is unchanged. Exploitation needs DKIM signing to be enabled for the hosted domain (it is off until configured) and, for the forgery to leave the server, a forward, alias, list or rule that carries the domain's mail to an outside address. The signer likewise signed a message submitted over authenticated SMTP as whatever hosted domain its From header named, a header authenticated SMTP does not hold to the submitting account, so that an account of one hosted domain could have mail written in the name of another hosted domain signed with that domain's key; this mattered where the server holds signed-in senders to their own envelope addresses (SmtpAuthenticatedSenderCheck, off by default), as the signature was then the remaining way for such mail to pass the other domain's DMARC policy.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.6 represents a critical failure in identity verification and trust management within the DomainKeys Identified Mail (DKIM) signing process. This flaw allows remote, unauthenticated attackers to forge email headers such that messages originating from external sources are signed with the DKIM private key of a domain hosted by the vulnerable server. The core technical deficiency lies in the server's logic for determining which DKIM identity to use when signing outgoing mail. Specifically, hMailServer was configured to sign every message during its first delivery pass based solely on the address present in the From header field, rather than validating that the sender had authenticated against that specific domain or possessed legitimate authority over it. This design choice ignores the fundamental security principle of least privilege and proper source validation, treating any incoming email as a candidate for signing under the identity specified in its headers without verifying the authenticity of that claim.
From an operational perspective, this vulnerability enables sophisticated phishing campaigns and business email compromise attacks with high deliverability rates. When a remote attacker sends an inbound message to the hMailServer instance specifying a From address belonging to one of the hosted domains, the server processes this mail as if it were legitimate internal traffic. Before local delivery or further processing, the server applies its DKIM signature using the private key associated with that domain. Consequently, any subsequent forwarding, aliasing, distribution list expansion, Sieve redirect, mirror copy, journal entry, or quarantine release of this message will carry a valid cryptographic signature aligned with the forged From address. This means that even if the original inbound email is flagged as suspicious by receiving systems due to lack of authentication at submission time, the forwarded copies retain their DKIM and Domain-based Message Authentication, Reporting, and Conformance (DMARC) validity because they appear to originate from a trusted source within the organization's infrastructure.
The impact extends beyond simple external-to-internal forgery. The vulnerability also affects mail submitted via authenticated SMTP sessions. In this scenario, an attacker who has valid credentials for one hosted domain can submit emails with a From header belonging to a different hosted domain on the same server. While many servers enforce strict binding between the authenticated user and the envelope sender or From address, hMailServer's DKIM signing mechanism did not strictly enforce this alignment during the signature generation phase unless specific hardening settings were enabled. This allows an account from Domain A to send mail impersonating Domain B, which is then signed with Domain B's key. If the server configuration does not explicitly check that the authenticated sender matches the envelope address (a feature controlled by the SmtpAuthenticatedSenderCheck setting, which was off by default), this forged message will pass DMARC checks at receiving domains for both DKIM and alignment requirements, significantly increasing the success rate of social engineering attacks targeting users who trust emails bearing valid signatures from their organization's peers.
This vulnerability maps directly to CWE-287: Improper Authentication, as the system fails to adequately verify the identity of the sender before granting them the ability to sign messages with a privileged key. It also aligns with MITRE ATT&CK technique T1434.003: Domain Fronting, although in this context it is more accurately described as DKIM Key Forgery or Identity Spoofing via Misconfigured Signing Policies. The exploitation requires that DKIM signing be enabled for the targeted domain and that there exists a mechanism to route the forged message outside of the local network, such as through forwarders, aliases, distribution lists with external members, or mail rules directing traffic outward. Without these routing mechanisms in place, the signed messages would remain internal and not reach external recipients where DMARC policies are enforced.
Mitigation strategies must focus on enforcing strict identity binding between authenticated users and message headers, as well as validating DKIM signing contexts against actual sender authority. Administrators should immediately enable the SmtpAuthenticatedSenderCheck setting to ensure that authenticated SMTP submissions strictly adhere to the envelope sender address, preventing cross-domain impersonation within the same server instance. Furthermore, organizations must review their mail flow rules and forwarding configurations to minimize unnecessary external routing of internal messages where possible. While there is no patch available for these specific legacy versions, upgrading to a supported version of hMailServer that implements robust DKIM signing logic with proper source validation is essential. Security teams should also implement strict DMARC policies at the receiving end to detect anomalies in signature alignment and consider deploying email authentication monitoring tools to identify unauthorized use of organizational domains for outbound mail signing.