hMailServer CVE-2026-107567

Two concrete conditions must both hold. (1) DKIM signing must be explicitly enabled for a hosted domain - it is OFF by default until an operator configures a signing key, so default installs are not exploitable. (2) For the forged, signed message to actually leave the server, the hosted domain must have an external-facing relay path: an account forward, a mail-rule forward/copy, a Sieve redirect, an alias or distribution/managed list or journal with an outside member, a mirror copy, or a quarantine release. A separate variant applies over authenticated SMTP: a logged-in account can have mail signed in the name of a DIFFERENT hosted domain named in its From header (authenticated SMTP does not bind the From to the submitting account); this matters chiefly when SmtpAuthenticatedSenderCheck is NOT enabled (it is off by default). Limiting factors: no special privileges or user interaction are needed from the attacker, but exploitation is gated by server-side DKIM configuration and the existence of an external forwarding path, which bounds real-world exposure.

Signals are consistent in pointing to a moderate, conditional risk rather than a drop-everything priority. The NVD CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, 7.5) correctly captures a network-reachable, unauthenticated, integrity-only flaw: an attacker can get the server to emit mail bearing a valid DKIM signature for a hosted domain, defeating DMARC at downstream receivers. No confidentiality or availability impact (C:N/A:N), which matches the DKIM-forgery nature of the bug. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation status is 'no public exploit identified at time of analysis.' Critically, the headline AV:N/AC:L/PR:N vector understates two real-world preconditions that the description makes explicit: DKIM signing must be enabled for the hosted domain (it is OFF until an operator configures it), AND a forward, alias, mailing list, Sieve redirect, rule, mirror/journal copy, or quarantine release must carry the signed mail to an external recipient for the forgery to actually leave the server. Those are target-side configuration dependencies, not attacker privileges, so PR:N remains technically correct, but they substantially narrow the exploitable population. Net: this is a genuine spoofing/domain-impersonation integrity flaw worth patching to v6.3.7 on any hMailServer host that signs DKIM and forwards mail externally, but it is not mass-exploitable against default installs, and the absence of KEV/EPSS/POC signals argues against widespread automated exploitation.

An attacker anywhere on the internet sends ordinary inbound SMTP mail to an hMailServer instance (6.0.0-6.3.6) that has DKIM signing enabled for a hosted domain, setting the From header to any address at that domain (e.g. ceo@victim-domain.com). On its first delivery pass the server signs the message with the domain's real DKIM key without checking that the sender authenticated; when an account forward, alias, mailing list, or rule then relays that message to an outside address, the forwarded copy carries a valid DKIM signature aligned with the forged From and passes DKIM/DMARC at the receiving provider. No public exploit code was identified in the provided data, but the attack requires only a crafted, unauthenticated inbound message.