CVE-2026-114489 in hMailServer
Summary
by MITRE • 10/21/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.6 represents a critical failure in access control mechanisms within both its REST and COM administration APIs. This flaw allows remote authenticated users, whose credentials are ostensibly restricted to managing specific named domains on a multi-tenant server, to escalate their privileges and modify global server configurations beyond the scope of their assigned permissions. The core technical issue lies in the absence of proper authorization checks when handling administrative requests that affect system-wide settings rather than just domain-specific data. Specifically, the API handlers do not validate whether the caller has sufficient rights to execute actions such as creating domain aliases, renaming domains, or modifying mail routing rules. This lack of enforcement means that a user with limited privileges can interact with endpoints designed for full-scope administrators, effectively bypassing the intended security boundaries between different tenants on the same server infrastructure.
From an operational perspective, this vulnerability enables several severe attack vectors that compromise both confidentiality and integrity of email communications. An attacker could create a domain alias pointing to any arbitrary name, thereby diverting mail destined for other tenants or legitimate domains to addresses controlled by the attacker. This facilitates unauthorized interception of sensitive information belonging to third parties. Furthermore, an attacker can rename a domain to one that the server does not host, potentially causing service disruption or confusion in email routing logic. More critically, the ability to modify rule actions allows an attacker to set bind-to-address, send-using-route, or script-function parameters to target internal addresses on the server's own network. By configuring routes with stored credentials or invoking event scripts via the COM API, attackers can execute arbitrary code or access sensitive system resources under the context of the mail service account. This effectively transforms a simple email configuration error into a pathway for lateral movement and potential remote code execution within the internal network.
The technical root cause is attributed to insufficient authorization checks in the underlying handlers. For instance, saving a domain alias via the COM API performs no authorization check at all, while renaming a domain only requires basic domain administrator status rather than full administrative privileges. Similarly, saving rules often only verifies that the caller can change the rule's owner, ignoring broader system-level constraints. This design flaw means that the application relies on implicit trust in the input parameters or session context without verifying the actual permission level of the authenticated user against the requested action. The vulnerability aligns with CWE-269, which describes Improper Privilege Management, as it involves a failure to enforce proper access control policies for elevated functions. Additionally, this behavior is consistent with MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials to gain unauthorized access and perform actions that should be restricted based on role-based access controls.
To mitigate this vulnerability, organizations running affected versions of hMailServer must immediately upgrade to a patched version released by Progressive Robot after the disclosure of these issues. Until an update is applied, administrators should restrict network exposure of the administration APIs to trusted internal networks only and implement strict firewall rules that limit access to authorized IP addresses. It is also advisable to review existing API keys and user accounts to ensure they adhere to the principle of least privilege, removing any unnecessary permissions from domain-specific users. Regular audits of mail routing configurations and event scripts can help detect unauthorized changes early. Given the severity of potential data exfiltration and lateral movement enabled by this flaw, treating it as a high-priority security incident is essential for maintaining the integrity of multi-tenant email environments.