hMailServer EUVD-2026-107317

Exploitation requires a hosted hMailServer account configured to collect mail from an external POP3/IMAP account AND to forward/redirect that mail to an outside address - this collect-and-forward path is the core precondition. The attacker must be able to deposit a message (with a forged From header at a domain the server hosts) into that externally collected mailbox, and must know such a mailbox exists. No non-default server setting, hostname record, or DMARC policy is needed - the bug works against default configurations and even survives strict DMARC alignment because the Sender Rewriting Scheme leaves a hosted-domain envelope sender unmodified. A notable limiting/enabling nuance: an account holder who adds their own external account can supply mail from a server they control, which is significant where SmtpAuthenticatedSenderCheck would otherwise restrict signed-in senders to their own addresses. The High attack complexity stems from needing a suitable pre-existing forwarding relationship rather than any authentication.

This is a domain-spoofing / sender-authentication bypass (CWE-348, Reliance on a Less Trusted Source) rather than a code-execution or data-leak flaw. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, base 5.9) is internally consistent with the description: it is remotely reachable by an unauthenticated attacker (PR:N) with no user interaction, but carries High attack complexity because the attacker must first know of a specific mailbox that an hMailServer account collects from and forwards to an outside address - a precondition outside the attacker's control. Impact is purely integrity (I:H): the server re-sends attacker-authored mail with an envelope sender at a hosted domain that then passes SPF and DMARC (even under strict alignment) at downstream receivers, enabling highly convincing spoofing/phishing. No EPSS score, SSVC decision, KEV listing, or POC was supplied with this input, so exploitation likelihood cannot be quantified from the data. Signals are therefore not in conflict so much as sparse: a genuinely useful integrity primitive for phishing, but gated by a real-world precondition (AC:H) and lacking any exploitation-prevalence evidence. Net: a medium-severity, situationally valuable bug - worth patching promptly on affected hMailServer instances, but not an emergency on the level of a wormable or auth-bypass-to-RCE issue. Note the input 'Information Disclosure' tag is inconsistent with the CVSS vector, which shows C:N/I:H - this is an integrity/spoofing flaw, not disclosure.

An attacker learns that a victim hMailServer account pulls mail from an external POP3/IMAP mailbox and auto-forwards it to an outside address. The attacker sends a message into that external mailbox with a From header forged to a domain the hMailServer hosts; the server downloads it (no SMTP envelope of its own), adopts the forged From as the envelope sender, and forwards it out, so the receiver's SPF and DMARC checks pass for the spoofed domain. No public exploit identified at time of analysis, and the High attack complexity reflects the need to know a suitable collected-and-forwarded mailbox.