CVE-2026-114490 is an incorrect authorization vulnerability in Progressive Robot Ltd's hMailServer versions 6.3.4 through 6.3.6. It affects the COM administration API, allowing accounts assigned the serveradmin role with a restricted domain list to gain full server administrator privileges over all domains. This bypasses intended role restrictions, enabling unauthorized access to all domain accounts, mail, server settings, and the ability to create additional server-administrator accounts. Accounts with serveradmin role but no domain list and other roles like help desk or auditor are not affected.
CVE-2026-114489 is a high-severity vulnerability in Progressive Robot Ltd hMailServer versions 6.0.0 through 6.3.6. It involves missing authorization checks in the REST and COM administration APIs, allowing remote authenticated users with domain-confined credentials to perform unauthorized changes beyond their allowed domains on multi-tenant servers. Attackers can manipulate mail routing, domain configurations, domain aliases, domain renaming, and rule actions, potentially diverting or denying mail for other tenants. The vulnerability arises because authorization gates do not properly restrict these actions to the caller's permitted scope.
Not failing securely in the anti-virus attachment-stripping action of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have a message that 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 default action deletes the message), the server keeps one text part of an infected message and replaces every attachment with a note. A message whose single part is not text - a program or an archive sent as the whole message, a message carried whole, a file declared an attachment, or an S/MIME message signed as one part, whose content the recipient's mail client opens - had no part the action could pick out, and was delivered as it arrived, with the content the scanner had found and nothing but a line in the application log to show it. Any sender can write such a message.
Progressive Robot Ltd hMailServer versions 6.0.0 through 6.3.6 have a vulnerability where the original sender is insufficiently preserved during mail forwarding. This allows a remote unauthenticated attacker to send mail that appears to pass the domain's DMARC policy by exploiting forwarding mechanisms combined with certain server settings. Exploitation requires specific forwarding configurations and enabling of Sender Rewriting Scheme or envelope sender rewriting. The vulnerability can cause mail to be delivered as if it originated from the hosted domain, potentially bypassing SPF and DMARC checks.
CVE-2026-114477 is a missing authorization vulnerability in Progressive Robot Ltd's hMailServer versions 6.2.25 through 6.3.6. It allows a remote authenticated user with credentials confined to specific named domains to access server-wide traffic history metrics that should be restricted. The exposed data consists of aggregate operational counters over the last 30 days, not individual messages or account details. The flaw arises because the metrics route does not enforce domain confinement checks, unlike other report routes. The vulnerability has a medium severity with a CVSS score of 4.3.
CVE-2026-114476 is an incorrect authorization vulnerability in the REST administration API of Progressive Robot Ltd's hMailServer versions 6.3.4 through 6.3.6. It allows a remote authenticated user with manage_roles permission in certain domains or assigned the serveradmin role with domain lists to escalate privileges to full server administrator authority by exploiting a flaw in role removal logic. Specifically, the API route for deleting role assignments does not properly verify authorization after role removal, enabling privilege escalation and unauthorized access.
CVE-2026-114475 is a missing authorization vulnerability in Progressive Robot Ltd's hMailServer versions 6.3.4 through 6.3.6. It allows a remote authenticated user with credentials confined to specific named domains to improperly modify custom roles assigned to accounts in other domains. This includes creating, updating, and deleting custom roles beyond their authorized scope. However, the vulnerability does not allow elevation to server administrator privileges via custom roles.
CVE-2026-114474 is a medium severity vulnerability in Progressive Robot Ltd hMailServer versions 6.0.0 through 6.3.6. It involves the use of a less trusted source for the envelope sender address when downloading mail from external POP3 or IMAP accounts. This flaw allows a remote unauthenticated attacker to send mail that appears to originate from a domain hosted by the server, passing SPF and DMARC checks at receiving mail servers. The vulnerability arises because the server uses the From header address as the envelope sender without proper validation, enabling spoofing of the envelope sender domain. No non-default settings or DMARC policies are required for exploitation. The attacker must know a mailbox that the server collects mail for and forwards externally. No known exploits are reported in the wild, and no official patch information is provided.
CVE-2026-114473 is an incorrect authorization vulnerability in the Sender Rewriting Scheme (SRS) implementation of Progressive Robot Ltd's hMailServer versions 6.2.1 through 6.3.6. The flaw allows remote attackers holding a valid SRS address to relay mail through the server to external addresses without proper SMTP authentication. This occurs because the server treats all messages to valid SRS addresses as local deliveries, bypassing relay restrictions. SRS is disabled by default in hMailServer.
CVE-2026-114472 is a low-severity vulnerability in Progressive Robot Ltd's hMailServer versions 6.0.0 through 6.3.6. It involves an insufficient resource pool in the ACME HTTP-01 challenge responder, which handles TLS certificate issuance and renewal. The responder accepts only one connection at a time and waits up to five seconds for a request, allowing unauthenticated remote attackers to hold the connection idle and cause certificate validation failures. This can lead to certificate expiration and subsequent TLS refusal by clients, although the mail service continues to operate with the existing certificate until expiration. Version 6.3.7 improves this by allowing up to 64 simultaneous connections, mitigating the issue by requiring an attacker to maintain many idle connections concurrently to cause disruption.
CVE-2026-114471 is a vulnerability in Progressive Robot Ltd's hMailServer SMTP server versions 6.0.0 through 6.3.6. It involves insertion of sensitive authentication information into log files when SMTP logging is enabled. Certain authentication credentials, including PLAIN passwords sent in non-standard ways, OAuth 2.0 bearer tokens, SCRAM-SHA-256 client proofs, and GSSAPI authenticators, may be logged in cleartext or partially exposed. SMTP logging is off by default, but on Windows systems before version 6.3.6, the log folder permissions allowed any local user to read the logs, increasing risk of credential exposure.
CVE-2026-114470 is a Cross-Site Request Forgery (CSRF) vulnerability in the REST API of Progressive Robot Ltd's hMailServer versions 6.0.0 through 6.3.6. It allows a remote attacker to cause an authenticated user's browser to perform state-changing actions without their consent. The vulnerability arises because the REST API uses HTTP Basic authentication, which browsers cache and send automatically with requests, including cross-origin form submissions. The server does not enforce CSRF protections on HTTP Basic authentication, enabling blind forgery of actions such as creating domains, accounts, or API keys by an attacker controlling a malicious webpage visited by an authenticated user. The attacker cannot read the responses to these forged requests.
Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.6 allow a local authenticated user to run code as the mail server's high-privileged accounts when the product is installed in a folder whose permissions are inherited from a writable parent, such as the root of a drive. The installer places the server's programs in the Bin folder of the program folder and gives neither the program folder nor Bin any permissions of their own, so they inherit the parent's. Under the default location, Program Files, ordinary users receive only read and execute and the configuration is not affected; but the installer accepts any path without warning, and a program folder at the root of an NTFS volume inherits write access for a broad group - Authenticated Users (Modify) on a Windows client, Users (create files and folders) on Windows Server. A local user without administrator rights can then alter or replace the service program, which runs as LocalSystem or as the service's virtual account, or the programs an administrator runs elevated from Bin during setup and maintenance, or place a library in Bin that those programs load in place of the system copy, gaining code execution with those privileges. The default Program Files installation is not affected.
Unchecked input for a loop condition in Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to stop the server carrying mail. The server bounds the mail it generates in response to a message - a rule forward, reply or copy, an account forward, a Sieve redirect, vacation or notify, a bounce, an out-of-office reply - by a counter it carries in the message's X-hMailServer-LoopCount header, and makes no more once the counter reaches the configured rule loop limit (5 by default); that is what ends a forwarding or auto-reply cycle in a bounded number of hops. X-hMailServer-LoopCount is an ordinary header that is not stripped from mail arriving from outside, and the server read it with a signed conversion and no validation, so a count below zero passed every test against the limit: a sender who sets X-hMailServer-LoopCount to a negative value, or on the Linux builds to a value above the 32-bit signed range that the conversion wraps to a negative one, lifts the bound, and a message that enters a generated-mail cycle then loops up to about two thousand million times, each hop a queued message and a delivery, filling the queue and disk and stopping mail service. The Sieve notify action (from 6.2.22) consulted no limit at all, and its increment of the count could overflow a signed integer; and an account could reset the counter on its own mail through a Sieve editheader of the header (from 6.2.22) or a rule Set header value action (all versions) ahead of a forward or redirect.
Missing authorization in the Sieve editheader action (6.2.22 through 6.3.6) and in the mail-rule Set header value action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to make the server send mail as any address, DKIM-signed where the address is at a domain the server signs for. A Sieve script's editheader (addheader/deleteheader) could add or delete any header field except Received and Return-Path, and the server applies a script's header edits before it queues a redirect, so the redirected copy is sent as the script left it. The server signs a message's first delivery pass as the domain named in its From header wherever it signs DKIM for that domain and the message carries no signature of it. A script could therefore delete and re-add From - another account's address, or anyone's at a hosted domain - and redirect, so the server sent the message in that name and, for a hosted domain, signed it with that domain's DKIM key, a forgery aligned to pass the domain's DMARC; or, where another sender's domain is one the server signs for, delete the DKIM-Signature that sender's message arrived with, alter a field, and redirect, so the server re-signed the altered message as that sender's domain. editheader placed no restriction on From, Sender, Resent-From, Resent-Sender or DKIM-Signature. The editheader action was introduced in 6.2.22. In the mail-rule engine, a domain's or an account's rule's Set header value action could likewise set From, Sender, Resent-From, Resent-Sender or DKIM-Signature ahead of a forward or a copy, 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 the server forward or copy a message in the name of any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key.
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.
Use of a less trusted source in the DKIM signing of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write signed with the DKIM key of a domain the server hosts, so that it passes DKIM and DMARC for that domain at other receivers. With DKIM signing enabled for a hosted domain, the server signed every message on its first delivery pass as the domain named in its From header, before local delivery, whatever the message's origin and without checking that its sender had authenticated. A sender anywhere could therefore send the server, as ordinary inbound mail, a message whose From is any address at such a domain, and the server signed it with that domain's key. Every copy the server then sent on to an address outside carried a valid signature aligned with the forged From, whatever the domain's DMARC policy: an account's forward, a mail rule's forward or copy, a Sieve redirect, an alias or distribution list with an outside member, the mirror copy, a managed-list or journal copy, or a message released from quarantine. A signed copy can also be re-sent to other recipients while the domain's key is unchanged. Exploitation needs DKIM signing to be enabled for the hosted domain (it is off until configured) and, for the forgery to leave the server, a forward, alias, list or rule that carries the domain's mail to an outside address. The signer likewise signed a message submitted over authenticated SMTP as whatever hosted domain its From header named, a header authenticated SMTP does not hold to the submitting account, so that an account of one hosted domain could have mail written in the name of another hosted domain signed with that domain's key; this mattered where the server holds signed-in senders to their own envelope addresses (SmtpAuthenticatedSenderCheck, off by default), as the signature was then the remaining way for such mail to pass the other domain's DMARC policy.
CVE-2026-107586 is a medium severity vulnerability in Progressive Robot Ltd hMailServer versions 6.2.28 through 6.3.5. It involves uncontrolled eviction in the browser session table of the REST API, allowing a remote authenticated user to forcibly end other users' sessions by filling the session table. This occurs because the session table, shared across all accounts and administrative sessions, evicts the least recently used session when full without limiting the number of sessions per account. The vulnerability can cause denial of service for webmail and administration sessions by repeatedly signing in and filling the session table.
CVE-2026-107585 is a medium severity vulnerability in Progressive Robot Ltd's hMailServer versions 6.3.4 and 6.3.5. It involves uncontrolled eviction in the pending sign-in tables of the REST API, allowing a remote unauthenticated attacker to disrupt other users' OpenID Connect, SAML, and passkey sign-ins. Attackers can repeatedly initiate sign-ins to evict legitimate pending sign-ins, causing denial of single sign-on and passkey authentication for affected users.
Progressive Robot hMailServer 6.0.0 through 6.3.5 fails open when applying DANE (RFC 7672) to outbound SMTP delivery. The server's validating DNSSEC resolver treated a TLSA or MX lookup that did not complete (no answer, SERVFAIL, a malformed reply), an answer without the requested records and without an NSEC/NSEC3 proof of their absence, and an answer whose records carried no applicable RRSIG as if the recipient domain were unsigned, and from 6.2.19 it also delivered to mail exchangers taken from an unvalidated MX lookup that the DNSSEC-validated MX record set did not name. An attacker who can drop, forge or strip DNS answers on the path to the server's resolver, at the resolver, or between the resolver and the recipient domain's name servers, and who holds an active position on the SMTP path, can thereby disable DANE for a DNSSEC-signed recipient domain and cause messages to be delivered in cleartext or to a host of the attacker's choosing with an arbitrary certificate, where they can be read and modified.