hMailServer EUVD-2026-104408

Requires a valid authenticated principal on the server: either any user able to install a Sieve script using the editheader (addheader/deleteheader) action (introduced in 6.2.22), or any owner of a domain/account mail rule using the 'Set header value' action (from 6.0.0), including an account acting on its own rules over COM, a domain administrator, or a domain-scoped REST API key (over the REST API from 6.3.4). The server places no restriction on editing From, Sender, Resent-From, Resent-Sender, or DKIM-Signature and applies header edits before queuing a redirect/forward. The most severe outcome - a cryptographically valid, DMARC-aligning forgery - is LIMITED to cases where the impersonated address is at a domain the server hosts with DKIM signing enabled and the message carries no existing signature of that domain; outside those conditions the attacker can still spoof the From address but without a valid DKIM signature. Overall limiting factor: an authenticated account is required (no unauthenticated path), so risk is concentrated in multi-tenant/shared-hosting deployments.

This is a genuine but conditional email-authenticity (integrity) flaw rather than a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5 Medium) is internally consistent: network-reachable, low complexity, but requiring an authenticated low-privilege account (PR:L) and producing only integrity impact (C:N/A:N) - the harm is forged, DKIM-signed, DMARC-aligned mail, not data theft or outage. No EPSS score, no CISA KEV listing, no SSVC decision data, and no public POC were provided, so there is no signal of active or imminent mass exploitation; per the input this is 'no public exploit identified at time of analysis.' The realistic priority is elevated specifically for operators who run hMailServer as a multi-tenant / shared-hosting mail server with DKIM signing enabled, because an authenticated tenant can impersonate any other account or hosted domain with a cryptographically valid DKIM signature - a potent BEC/phishing primitive. For single-tenant or non-DKIM deployments the impact degrades to ordinary From-spoofing. Note a mild tension between the 'Authentication Bypass' tag and the actual weakness (CWE-862 Missing Authorization, exploited by an already-authenticated user) - this is an authorization/privilege-boundary flaw, not an authentication bypass.

An authenticated user on a shared hMailServer host (or a domain administrator / domain-scoped REST API key) writes a Sieve script using the editheader action - or a mail rule using 'Set header value' - to delete and re-add the From header as another account or a hosted domain's address, then triggers a redirect/forward. Because the server applies header edits before queuing the redirect and signs the first delivery pass for domains it hosts, it sends the message in the victim's name with a valid DKIM signature that passes DMARC. No public exploit code is identified at time of analysis, but the technique is directly reproducible from the vendor's own description.