CVE-2026-114490 in hMailServer
Summary
by MITRE • 10/22/2026
Incorrect authorization in the COM administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows an account assigned the serveradmin role with a list of domains - a credential an administrator may create meaning to confine it to those domains - to act as the whole-server administrator over COM. Administrator roles are meant to confine such a credential to the domains its list names, and the REST API did not take it for the server administrator, but the COM API's server-administrator check read the administer_server permission as the whole server whatever list the grant carried. So the credential signed in through the Control Panel, or through a script run on the server, as the server administrator of every domain: it could read and change every domain's accounts and mail, rename any domain, map a domain alias onto any, write the server's settings and secrets, and create further server-administrator accounts. The COM API's domain-administrator check, asked with no domain, likewise let an account assigned the domainadmin role with a list of domains that leaves out the account's own domain administer that domain's ordinary accounts over COM. An account holding serveradmin with no list is the server administrator by design and is unaffected, as are the help desk, auditor and custom roles.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.3.4 through 6.3.6 represents a critical flaw within the Component Object Model administration API, specifically involving incorrect authorization logic that undermines role-based access control boundaries. The core issue stems from a discrepancy between how administrative privileges are enforced across different interfaces of the application. While the REST API correctly respects domain-specific restrictions for administrators with limited scope, the COM API fails to apply these constraints when checking server-level permissions. This architectural inconsistency allows credentials intended to be confined to specific domains to escalate their privileges and operate as full system administrators over the entire mail infrastructure via the COM interface.
An account assigned the serveradmin role typically includes a list of domains that an administrator is permitted to manage, effectively restricting their operational scope to those designated areas. However, when such a credential authenticates through the Control Panel or executes scripts on the server using the COM API, the system incorrectly interprets the administer_server permission as granting unrestricted access regardless of the domain list attached to the grant. Consequently, an administrator meant to oversee only a subset of domains gains the ability to read and modify accounts and mail for every domain hosted on the server. This includes renaming any domain, mapping domain aliases arbitrarily, writing sensitive server settings and secrets, and creating additional server-administrator accounts with elevated privileges.
The vulnerability also affects domain administrators who are assigned specific lists of manageable domains. When a user holding the domainadmin role attempts to administer an ordinary account via the COM API without specifying a target domain in their request, the authorization check erroneously permits access to that domain even if it is not included in the administrator's designated list. This bypasses the intended isolation between different administrative zones within the mail server environment. Notably, accounts holding the serveradmin role with no specific domain list are unaffected by this flaw as they are designed to have full server-wide authority by default. Similarly, roles such as help desk, auditor, and custom-defined roles remain secure against this particular exploitation vector because their permission models do not trigger the flawed COM API logic in the same manner.
From a technical classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, where an actor is able to elevate privileges beyond what was intended by the system design. The ability of a user to perform actions outside their assigned scope constitutes a significant breach of access control policies. In terms of offensive security frameworks, this flaw facilitates lateral movement and privilege escalation within the application layer, allowing attackers who compromise a limited-admin account to gain complete control over the mail server infrastructure. This corresponds to ATT&CK techniques related to Account Manipulation and Defense Evasion, as an attacker could create new administrative accounts or modify existing configurations to maintain persistent access while evading detection mechanisms that rely on standard role-based boundaries.
The operational impact of this vulnerability is severe, potentially leading to total compromise of the mail server's integrity and confidentiality. Attackers can exfiltrate sensitive email data from all domains, disrupt service by altering critical settings, or establish backdoors through new administrative accounts. Mitigation strategies should prioritize immediate patching to version 6.3.7 or later where this authorization check has been corrected to properly validate domain lists against COM API requests. In the interim, organizations running affected versions should restrict network access to the COM interface and enforce strict monitoring of administrative actions performed via scripts or control panel interactions. Additionally, implementing principle of least privilege by ensuring that no single account holds unrestricted serveradmin rights unless absolutely necessary can reduce the blast radius if such an account is compromised. Regular audits of user roles and permissions are essential to detect any unauthorized modifications resulting from this flaw.