CVE-2026-107568 in hMailServer
Summary
by MITRE • 10/19/2026
Missing authorization in the Sieve notify action (6.2.22 through 6.3.6) and in the mail-rule Reply action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. A Sieve notify sends a notification message, and its :from tag names the sender; the server set the notification's From header to that :from as the script wrote it, without checking that the address belongs to the account - the check that the Sieve vacation action applies to its own :from, and that the server applies to the sender of mail queued over COM or sent from the webmail. An account that can store a Sieve script (over ManageSieve, the REST API's self-service filter, or the administration interface) could therefore have the server send a notification from any address, on this server or anywhere; and where the claimed address is at a domain the server hosts with DKIM signing enabled, the server signed the notification with that domain's DKIM key, because it signs by the From header's domain, producing forged mail aligned to pass the domain's DMARC policy. The notify action and this behaviour were introduced in 6.2.22. In the mail-rule engine, a rule's Reply was likewise sent from whatever address the action named, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have a domain's or an account's rule reply from any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.2.22 through 6.3.6 represents a critical failure in access control and identity verification mechanisms within its mail processing engine. This flaw allows authenticated users to bypass standard authorization checks, enabling them to send emails that appear to originate from any arbitrary email address rather than their own assigned account. The issue manifests primarily through two distinct components of the server: the Sieve scripting language's notify action and the legacy mail-rule Reply action. In both cases, the server fails to validate whether the sender identity specified in the outgoing message actually belongs to or is authorized by the authenticated user executing the script or rule. This lack of enforcement creates a significant avenue for email spoofing and impersonation attacks that can undermine organizational trust and security postures.
In the context of Sieve scripting, specifically version 6.2.22 through 6.3.6, the notify action is designed to send notification messages based on specific triggers. The vulnerability lies in how the server handles the :from tag within this action. When a script specifies a sender address via the :from parameter, hMailServer directly sets the From header of the resulting notification message to that value without performing any verification against the authenticated user's account identity. This behavior stands in stark contrast to other actions like vacation responses, which correctly enforce checks ensuring the sender is associated with the account initiating the action. Consequently, an attacker who gains access to a Sieve script storage mechanism—whether through ManageSieve, the REST API self-service filter interface, or the administration console—can craft scripts that instruct the server to send notifications from any email address they choose. This capability effectively neutralizes basic sender verification controls and allows for precise impersonation of internal staff, external partners, or trusted services.
The impact is further exacerbated by the integration with DomainKeys Identified Mail (DKIM) signing mechanisms present in hMailServer versions 6.0.0 through 6.3.6 regarding mail-rule Reply actions. When a user configures an auto-reply rule via COM interfaces, domain administrator privileges, or REST API keys restricted to a specific domain, the server sends replies from whatever address is named in the reply action configuration. If this configured sender address belongs to a domain hosted by hMailServer that has DKIM signing enabled, the server automatically signs the outgoing message using that domain's private key. Because DKIM signatures are validated based on the From header's domain, messages forged with arbitrary addresses from authorized domains will successfully pass DMARC alignment checks. This means an attacker can not only spoof any address but also ensure those emails appear cryptographically authentic to receiving mail servers, significantly increasing their deliverability and likelihood of deceiving recipients or bypassing security filters that rely on DKIM/DMARC validation.
From a technical perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-915 Improper Control of Dynamically-Managed Code Identifiers if viewed through the lens of script injection leading to unauthorized state changes in mail routing logic. It also maps closely to MITRE ATT&CK techniques such as T1498 Network Effect: Reflection Amplification or more specifically T1078 Valid Accounts combined with T1566 Phishing, where valid credentials are used to facilitate the creation of deceptive communications. The root cause is a fundamental design oversight in the mail submission pipeline where identity assertions made by application-level scripts and rules are accepted as authoritative without cross-referencing them against the actual authentication context or account permissions. This allows lateral movement within an organization's email infrastructure, enabling attackers to escalate privileges from simple mailbox access to full domain impersonation capabilities.
Mitigation strategies must focus on immediate patching and configuration hardening until updates are applied. Organizations running affected versions of hMailServer should upgrade to a version that addresses these authorization flaws as soon as possible. In the interim, administrators can mitigate risk by disabling DKIM signing for domains where unauthorized sender modification poses a high threat, although this reduces overall email authentication integrity. Additionally, restricting access to Sieve script management interfaces and mail-rule configuration tools to only those users who absolutely require such privileges can limit the attack surface. Implementing strict monitoring of outbound SMTP traffic for anomalies in From headers relative to authenticated user identities may also help detect exploitation attempts before they result in successful phishing or fraud campaigns. Regular audits of server configurations against industry standards like NIST SP 800-53 controls for access control and identity management are recommended to ensure robust defenses against similar logic flaws in the future.