CVE-2026-107568
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
Missing authorization in the Sieve notify action (versions 6.2.22 through 6.3.6) and in the mail-rule Reply action (versions 6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. The server sets the From header to the :from value from the Sieve script or Reply action without verifying that the address belongs to the account. If the claimed address is at a domain hosted by the server with DKIM signing enabled, the message is signed with that domain's key, producing forged mail aligned to pass the domain's DMARC policy.
Risk Assessment
An attacker with an account on hMailServer can send spoofed messages from any address, including domains hosted on the server, which will pass DKIM and DMARC verification. This can lead to phishing, spoofing, and loss of trust in the organization's domain.
Recommendation
Update hMailServer to a version later than 6.3.6, which contains the authorization fix for the Sieve notify and Reply actions. Until the update, restrict the ability to create Sieve scripts and mail rules and monitor for unusual sends from the organization's domains.
Other vulnerabilities in hMailServer
See all- CVE-2026-100741Critical
Eval injection vulnerability in hMailServer (versions 6.0.0-6.3.3) allows a remote, unauthenticated attacker to execute arbitrary JScript in the service process with service account privileges. It requires non-default configuration: event scripting enabled, JScript as script language, and an OnClientValidatePassword handler defined. Exploitation uses a password with backslash and apostrophe that is not properly escaped.
- CVE-2026-114490High
Incorrect authorization in the COM administration API of hMailServer 6.3.4 through 6.3.6 allows an account with the serveradmin role limited to a list of domains to act as the whole-server administrator over COM. Such an account can read and change every domain's accounts and mail, rename domains, map aliases, modify server settings and secrets, and create further server-administrator accounts.
- CVE-2026-114489High
Missing authorization in the REST and COM administration APIs of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to change mail routing and domain configuration beyond those domains on a multi-tenant server. This includes creating a domain alias for any name, renaming a domain, setting rule actions (bind-to-address, send-using-route, script-function), and setting the domain's relay host to an address on the server's own network.
- CVE-2026-114479Medium
In hMailServer 6.0.0 through 6.3.6, the anti-virus attachment-stripping action does not fail securely, allowing a remote unauthenticated attacker to have a message the server's virus scanner found infected delivered to the recipient's mailbox unchanged. With virus scanning enabled and its action set to remove attachments and deliver the text, the server keeps one text part and replaces every attachment with a note. A message whose single part is not text has no part the action could pick out and is delivered as it arrived.
- CVE-2026-114478Medium
A vulnerability in hMailServer versions 6.0.0 through 6.3.6 insufficiently preserves the original sender when forwarding mail. A remote unauthenticated attacker can send a message with a From address in a hosted domain, and the server will forward it so that it passes SPF and DMARC checks for that domain at other receivers, even though the message did not originally pass DMARC.
- CVE-2026-114477Medium
In hMailServer versions 6.2.25 through 6.3.6, missing authorization in the REST metrics route allows a remote authenticated user whose credential is confined to named domains to read the server-wide traffic history. GET /api/v1/metrics/history returns server-wide traffic counters over the last 30 days, which carry no domain information.
- CVE-2026-114476High
Incorrect authorization in the REST administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential holds the manage_roles permission in named domains to obtain the server administrator's authority. The DELETE /api/v1/role-assignments/{address} route checked only the credential's current authority, not the resulting authority, so such a credential could remove a narrowing role from a server-administrator-level account and then sign in as the server administrator after setting its password.
- CVE-2026-114475Medium
Missing authorization in the REST role-management routes of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to modify a custom role that accounts in other domains hold, and to create custom roles and delete any that no account holds. The routes that create, update and delete a custom role require the manage_roles permission, which only the serveradmin role holds; but a full-scope API key issued for named domains, and serveradmin assigned with a domain list, are serveradmin confined to those domains and hold manage_roles. The server's authorization gate did not refuse the three role routes to a confined credential and the route named no domain, so a credential issued to one tenant could raise or lower the permissions of a custom role assigned across other tenants.
- CVE-2026-114474Medium
Use of a less trusted source for the envelope sender in the external-account download of 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.
- CVE-2026-114473Medium
Incorrect authorization in the Sender Rewriting Scheme (SRS) of Progressive Robot hMailServer 6.2.1 through 6.3.6 allows a remote attacker to relay mail through the server to outside addresses. With SRS enabled, the server rewrites the envelope sender of mail it forwards to a signed SRS address at the forwarding domain, and passes a bounce to that address back to the original sender; but it took every message to a valid SRS address, whatever its sender, as delivery to a local recipient, so the relay rules and the SMTP authentication they require were not applied, and the message was delivered to the outside address the SRS address encodes. Anyone holding a valid SRS address of the server could have the server relay mail to the address it encodes for 21 days.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

