hMailServer flaws let forged email pass DKIM and DMARC
News
Published 19 Oct 2026
Updated 19 Oct 2026
7 min read
Summarize with
Progressive Robot hMailServer 6.3.7 fixes authorization flaws that let forged email leave a vulnerable server with a genuine DKIM signature and pass DMARC. The main flaw affects versions 6.0.0 through 6.3.6 when DKIM signing is configured for a hosted domain. A remote sender needs no account to trigger that signing, but an outward forwarding or similar delivery path is required for the unauthenticated forgery to reach external recipients.
The security release became public on October 17, 2026, at 23:52:19 UTC. The three related CNA records were published on October 19 at 15:34 UTC. This is a security fix for the Progressive Robot fork, with operational consequences for administrators who authorize their server to sign hosted domains.
Which installations and actions are affected
The product distinction matters. These disclosures identify Progressive Robot hMailServer, including its 6.x version ranges. They do not establish that historical upstream hMailServer 5.6 installations have the same behavior. Check the installed distribution and version before deciding whether a server falls within scope.
All five paths below are fixed in 6.3.7. The Sieve actions require an authenticated user with access to the relevant scripting capability. The corresponding mail-rule actions have a longer affected range, so checking only whether Sieve is enabled misses part of the exposure.
|
|
|
|---|---|---|
DKIM signing | 6.0.0-6.3.6 | |
Sieve notify | 6.2.22-6.3.6 | |
CVE-2026-107568 | Rule Reply | 6.0.0-6.3.6 |
Sieve editheader | 6.2.22-6.3.6 | |
CVE-2026-107566 | Set header value | 6.0.0-6.3.6 |
Affected releases of the Progressive Robot fork; fixed in 6.3.7.
CVE-2026-107568 lets an authenticated user choose an unauthorized From address through Sieve notify or a mail-rule Reply. CVE-2026-107566 covers Sieve editheader changes before a redirect, including rewriting From or Sender or removing a DKIM-Signature, and the corresponding Set header value rule action. When the claimed identity belongs to a hosted signing domain, those paths can produce a genuine signature under that domain's name.
DKIM signing is off for a new domain until an administrator configures it. Hosting a domain alone does not activate the vulnerable signer. Inventory the domains with signing enabled, including applicable alias signing, rather than assuming every hosted domain has identical exposure.
How an outside message gets a trusted signature
The main flaw, CVE-2026-107567, is in the decision to sign. On the first delivery pass, the vulnerable server selects a hosted signing domain using the message's attacker-controlled From header, without establishing that the sender is authorized to use that domain.
The project's technical advisory describes signing before local delivery. Ordinary inbound SMTP delivery is enough to reach that decision. An attacker does not need an open relay: a legitimate local recipient with an existing outward delivery path provides the route.
- Inbound delivery. An unauthenticated sender submits ordinary mail to a local address, claiming a From address at a hosted domain with DKIM signing enabled.
- Server signing. On its first delivery pass, the vulnerable server adds that hosted domain's signature without checking the sender's permission to use the claimed identity.
- Outward delivery. An account forward, Sieve redirect, alias, distribution list, mail rule, mirror, or another outward path carries the signed message to an external address.
- Receiver verification. The external receiver verifies a real signature whose signing domain matches the visible From domain. That result can satisfy DMARC even under a reject policy.
Without an outward path, the unauthenticated signed forgery stays in local mailboxes. Existing forwarding configuration supplies that path without requiring a recipient to take a new action after delivery.
Authenticated SMTP has a related authorization gap: an account can obtain another hosted domain's signature without permission to send as that address. Requiring SMTP login therefore does not, by itself, close every signing path described in the disclosure.
Why a reject policy does not stop this forgery
DKIM checks whether a signature verifies against the signing domain's published key. DMARC checks whether a passing DKIM or SPF identity matches the visible From domain under its domain-matching rules. Neither check establishes that the server correctly authorized the person who requested the signature.
Here, the legitimate signing server supplies the evidence the external receiver expects. A restrictive DMARC policy applies to authentication failures; a forged message with a passing, matching DKIM signature satisfies the authentication requirement. Changing the policy to reject does not repair that signing decision.
What the receiver verifies
The domain's public key verifies the signature, and the signing domain matches the From domain. Cryptographic verification succeeds.
What the signer failed to check
The sender was entitled to use the claimed address. That permission must be checked before the server signs.
This is unauthorized use of a legitimate signer, not broken cryptography or a universal DKIM or DMARC bypass. The disclosed failure does not require an attacker to steal the private key.
What administrators should do now
I would start with the actual signing configuration and delivery routes. Record the fork and version, each signing domain, and every path that sends local mail outward. Include account forwarding, aliases with external targets, distribution lists, Sieve scripts, mail rules, and mirrors.
Back up the database and data directory before upgrading, and follow the official upgrade guidance for the installed version and platform. Do not assume every older installation can use the same update mechanism. After installation, confirm that the running service is 6.3.7.
Installing 6.3.7 repairs the signing checks for new submissions. Review mail already queued during the upgrade: the advisory says those messages retain the earlier signing behavior. The upgrade does not revoke existing signatures. Where forged signatures were previously created, follow the project's key rotation guidance, including retirement of the old verification key.
A new selector alone does not end the validity of old signatures while the old public key remains available. Coordinate rotation with legitimate senders and account for DNS caching when retiring the old key.
For an upgrade delay, review the advisory's temporary restrictions with the effect on legitimate mail in mind. Disabling signing affects outgoing authentication, and removing account forwarding alone leaves other outward routes. Treat temporary configuration changes as containment while preparing the fixed release.
- Check authorization. Review which accounts can send as other hosted addresses. Authentication to SMTP is a login check, not blanket permission to use every domain on the server.
- Inspect scripts. Examine Sieve notify and editheader actions, plus mail-rule Reply and Set header value actions, for sender identities or header changes outside the account's authority.
- Preserve evidence. Keep relevant message files and server logs before changing rules or keys. Record the signing selector and outward destination for messages that need investigation.
- Retest delivery. Use controlled accounts and recipients to verify that unauthorized identities no longer receive a hosted-domain signature and that authorized outgoing mail still authenticates.
How to investigate a passing message
When investigating, I compare the receiving system's trusted Authentication-Results with the DKIM signing domain, selector, visible From, and Received chain. A passing result is evidence about authentication. The logs must establish whether the server had authority to sign that particular message.
The simplified header excerpt below illustrates the misleading outcome. It is not a captured incident or a complete signature. The important relationship is that the passing signing domain and the visible From domain match despite the original sender lacking authorization.
Illustrative receiver results, not a captured messagetext
From: billing@example.com Authentication-Results: mx.receiver.example; dkim=pass header.d=example.com header.s=mail; dmarc=pass header.from=example.com
Correlate the inbound session with local delivery and the later forward or rule action. For authenticated submissions, compare the logged account with its send-as permissions. A message using the server's normal IP address and selector still needs review when its origin or claimed sender is unexpected.
In our platform, Suped, DMARC monitoring helps review reported sources and authentication results, but aggregate reports do not prove mailbox-level authorization. Teams using our hosted DKIM can manage selector DNS records during rotation. Use the DKIM checker to validate published selector records, alongside server logs and controlled message tests.
Make authorization part of the recovery check
I would keep recovery open until the fixed service is running and the affected forwarding, scripting, and mail-rule paths have been checked. Test a permitted sender and an unauthorized identity separately, using addresses under the organization's control.
If the review identifies previously forged signatures, follow the key rotation guidance and document when the old key is retired. A successful legitimate test message confirms normal delivery; the unauthorized test establishes whether the signing boundary now holds.
Frequently asked questions
No. These disclosures identify the Progressive Robot fork and specific affected versions. Historical upstream 5.6 installations are not established as affected by this signing behavior. Check the installed distribution and configuration.
Yes. CVE-2026-107567 allows unauthenticated inbound mail to receive a hosted domain's signature when signing is configured. An outward forwarding or similar delivery path is required for that forgery to reach external recipients.
No. A forged message with a valid DKIM signature matching its From domain passes DMARC. The signer's authorization decision must be fixed; changing the DNS policy alone does not fix it.
No. Previously issued signatures remain verifiable while the required verification key is available and the signature remains otherwise valid. Follow the official rotation guidance where forged signatures were previously created.
