hMailServer EUVD-2026-107316

The Sender Rewriting Scheme (SRS) forwarding feature must be explicitly ENABLED - it is off by default, which is the primary limiting factor and excludes most deployments. The attacker must possess a valid, server-signed SRS address: either by being the recipient of a message the server forwarded (the envelope sender is rewritten to such an address), or by being an account holder who configures their account to forward to an outside mailbox and thereby mints one for an address of their choosing. The signed token is accepted for 21 days, giving a bounded abuse window. Affected versions are hMailServer 6.2.1 through 6.3.6; upgrading to 6.3.7 removes the flaw.

This is a medium-severity authorization flaw (CVSS 5.0, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N) that turns hMailServer into an open relay under a specific configuration. The signals are internally consistent but modest: the vector is network-reachable with low complexity, but it carries PR:L (per the precision rules, exploitation is authenticated/credential-bearing, since the attacker must hold a valid signed SRS token or an account), integrity impact only (I:L - abuse of the relay to send mail, no data disclosure or availability loss), and a scope change (S:C) reflecting that the abuse reaches external mail systems. No EPSS score, CISA KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this reads as a correctness/abuse issue rather than an urgent widespread threat. The single most important risk-limiting factor is that SRS is OFF BY DEFAULT, so only deployments that explicitly enabled Sender Rewriting Scheme forwarding are affected. Net: a real bug worth patching for sites running SRS (open relays invite spam, blocklisting, and reputation damage), but low real-world priority for the broad hMailServer population given the non-default prerequisite, authenticated/token precondition, and absence of exploitation signals.

On an hMailServer instance (6.2.1-6.3.6) with SRS enabled, an attacker who holds a valid signed SRS address - for example, a user whose account forwards to an external mailbox, or anyone who received a forwarded message bearing such an address - crafts a message to that SRS address. The server mistakes the valid SRS address for a local recipient, skips the relay rules and SMTP authentication that should apply, and forwards the message to the external address encoded in the token, which remains usable for 21 days. No public exploit code was identified at time of analysis.