Live › vulnerability › CVE-2026-114489
Go to dashboardProgressive Robot hMailServer 6.0.0 through 6.3.6 fails to check authorization on its REST and COM administration APIs, so a credential limited to certain domains can change mail routing and domain settings for other domains. An attacker in a shared multi-tenant server can create aliases that divert other tenants' mail to their own address, rename domains, or point relay and rule actions at the server's internal addresses and stored route credentials.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only servers running hMailServer 6.0.0 through 6.3.6 that host multiple tenants and give some users or API keys access limited to named domains are exposed. Single-tenant servers where every administrator controls all domains face much less risk, though any account with COM access can still alter its own rule actions.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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. A domain administrator, an account or API key given another role that manages accounts in named domains, or a full-scope API key issued for named domains could create a domain alias for any name (so that other tenants' mail for that name is diverted to an address the attacker controls, or denied), rename a domain to any name the server does not host, set a rule's bind-to-address, send-using-route or script-function action to reach one of the server's own addresses, a configured route's stored credentials or a function of the server's event script, and set the domain's relay host - which delivery then connects to with no address rule - to an address on the server's own network; and over the COM API any account could set the three rule actions on its own rules, where the script-function action runs at delivery. The authorization gate did not refuse these routes to a confined credential and the handlers were not given the caller; over COM the domain-alias save performed no authorization check at all, the domain rename required only a domain administrator, and a rule save required at most that the caller could change the rule's owner.
This page as .md · .json · in your agent: get_signal("CVE-2026-114489")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.