CVE-2026-114489: Missing Authorization in hMailServer
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.7 - Configuration
Keep the REST API disabled by setting RestApiPort=0 where it is not needed.
hMailServer REST API RestApiPort = 0 - Compensating control
On a multi-tenant server, do not give domain-administrator credentials, roles that manage accounts in named domains, or named-domain API keys to parties not trusted with the whole server.
- Operational
Review existing domain aliases, domain names, relay hosts, and account/domain rule actions for changes a confined credential should not have made; also review accounts' own rules for bind-to-address, send-using-route, and script-function actions. Perform this after upgrading because an upgrade does not undo existing changes.
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker must be authenticated. Exposure includes domain administrators, credentials restricted to managing accounts in named domains, and full-scope API keys issued for named domains; through COM, any account can modify the affected actions on its own rules.
Which deployments are most exposed?
Multi-tenant hMailServer deployments are most affected because a credential confined to particular domains can act on domains or routing outside its intended scope. The affected interfaces are the REST and COM administration APIs.
What should be reviewed while remediation is planned?
Review domain aliases, domain names, relay-host settings, and rule actions that bind to an address, send using a route, or invoke a script function. Also review which users and API keys have domain-management roles or are scoped to named domains.
Which versions are affected?
The affected range is hMailServer 6.0.0 through 6.3.6. A v6.3.7 release is referenced.