CVE-2026-114474 in hMailServerinfo

Summary

by MITRE • 10/21/2026

Use of a less trusted source for the envelope sender in the external-account download of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write in the name of a domain the server hosts sent on by the server with an envelope sender at that domain, so that it passes the domain's SPF and DMARC at other receivers. A message the server downloads from an external POP3 or IMAP account has no SMTP envelope of its own, and the server took the address in its From header as its envelope sender, whatever that address was. A forward or redirect of the downloaded message to an outside address then left with that address as its envelope sender, which the Sender Rewriting Scheme leaves alone for a hosted domain, so that the receiver's SPF check passed for the forged domain, aligned even under strict alignment, with no non-default setting, host name record or DMARC policy needed. An attacker needs to know a mailbox elsewhere that an account here collects and forwards to an outside address; an account holder who adds an external account of their own can collect from a server of their own, which matters where SmtpAuthenticatedSenderCheck holds signed-in senders to their own addresses.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/21/2026

The vulnerability identified in hMailServer versions 6.0.0 through 6.3.6 represents a critical flaw in the mail transfer agent's handling of envelope sender information during the retrieval and forwarding of messages from external accounts. This issue stems from an improper trust relationship where the server accepts the From header field as the authoritative source for the SMTP envelope sender address when processing downloaded emails via POP3 or IMAP protocols. In standard email operations, the envelope sender is distinct from the visible From header; it is established during the initial SMTP transaction and dictates who receives bounce messages and serves as the primary identifier for authentication checks such as SPF and DMARC. By conflating these two fields without sufficient validation, hMailServer creates a pathway for attackers to forge the origin of email traffic in a manner that bypasses standard anti-spam and anti-phishing defenses.

The technical mechanism of this exploitation relies on the specific behavior of the server when it downloads messages from an external mail account configured by a legitimate user. When such a message is retrieved, it lacks its own SMTP envelope because it was not transmitted via SMTP to hMailServer but rather pulled using IMAP or POP3 protocols. Instead of assigning a default envelope sender derived from the authenticated session or the server's identity, the software extracts the address listed in the From header and assigns it as the new envelope sender for subsequent forwarding operations. This logic flaw is particularly dangerous because it allows an attacker to craft messages with arbitrary domain names in the From field that are then relayed by hMailServer with those same domains appearing as the legitimate sending source in the SMTP transaction.

The operational impact of this vulnerability is severe, primarily facilitating sophisticated phishing and spoofing attacks that evade detection mechanisms like SPF and DMARC. When a user forwards or redirects one of these downloaded messages to an external recipient, the resulting email carries the forged domain name as its envelope sender. Because the Sender Rewriting Scheme (SRS) typically preserves addresses belonging to hosted domains rather than rewriting them for relay purposes, the forwarded message retains this forged identity. Consequently, receiving mail servers perform SPF and DMARC checks against hMailServer's IP address or hostname. Since hMailServer is authorized to send email on behalf of its hosted domain, these authentication checks pass successfully. This alignment occurs even under strict DMARC policies without requiring any specific host name records or non-default configurations, effectively allowing the attacker to impersonate trusted domains with high deliverability rates.

Exploitation requires a degree of social engineering or prior knowledge regarding the target infrastructure. An attacker must identify an account on the vulnerable hMailServer instance that collects mail from an external source and forwards it outward. The attack vector involves configuring this internal account to pull messages from a server controlled by the attacker, such as their own POP3 service. This method is effective even in environments where settings like SmtpAuthenticatedSenderCheck are enabled, which typically restrict senders to only those addresses associated with authenticated users. By leveraging the external account download feature rather than direct SMTP submission, the attacker circumvents these restrictions and utilizes the server's legitimate relay capabilities to distribute malicious content that appears authentic to downstream security filters.

Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is upgrading hMailServer to a version where this logic flaw has been corrected by the vendor, ensuring that envelope sender assignment follows strict RFC-compliant practices rather than relying on untrusted header fields. In environments where an upgrade is not immediately feasible, administrators should consider disabling the external account download feature if it is not strictly required for business operations. Additionally, implementing rigorous SPF and DMARC policies at the organizational level can help mitigate some downstream impacts by instructing receiving servers to reject messages that fail alignment checks, although this does not prevent the initial abuse of the server as a relay point. Security monitoring should also be enhanced to detect unusual patterns of email forwarding from external accounts, which may indicate active exploitation attempts against vulnerable instances.

Responsible

GitLab

Reservation

10/21/2026

Disclosure

10/21/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Interested in the pricing of exploits?

See the underground prices here!