CVE-2026-114476 in hMailServer
Summary
by MITRE • 10/21/2026
Incorrect authorization in the REST administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential holds the manage_roles permission in named domains - a full-scope API key issued for those domains, or an account assigned the serveradmin role with a list of domains - to obtain the server administrator's authority. An account's admin level gives it authority, and a role assigned to it replaces that authority, which is how an administrator narrows an account whose admin level is the server administrator's. The route that takes a role away (DELETE /api/v1/role-assignments/{address}) checked only that the credential takes in what the account held at the time, not what it would hold afterwards, so such a credential could take a narrowing role away from an account in its domains whose admin level is the server administrator's, returning it to the server administrator's authority, and, having set that account's password while it held the narrower role, sign in as the server administrator.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.3.4 through 6.3.6 represents a critical flaw within its REST administration API, specifically classified under CWE-285 Improper Authorization. This issue stems from an insufficient check during the revocation of role assignments, allowing authenticated users with specific permissions to escalate their privileges beyond intended boundaries. The core technical failure lies in the logic governing the DELETE /api/v1/role-assignments/{address} endpoint. When a user attempts to remove a role assignment from another account within domains they manage, the system validates whether the requesting credential possesses authority over that target account at the moment of execution. However, it fails to verify if this action would result in an unauthorized elevation of privilege for either party or violate security policies regarding administrative boundaries. This oversight creates a race condition-like scenario where the state change is permitted based on transient permissions rather than long-term policy compliance.
An attacker exploiting this flaw must first possess credentials that hold the manage_roles permission within named domains, such as a full-scope API key issued for those specific domains or an account assigned the serveradmin role with access to a list of domains. By leveraging these valid but limited privileges, the attacker can target an existing administrative account whose admin level is set to server administrator. The hMailServer architecture operates on a model where an account's base authority is defined by its admin level, while roles serve as modifiers that typically narrow or restrict this authority for security purposes. When a narrowing role is assigned to a high-privilege account, it reduces the effective permissions of that account. The vulnerability allows the attacker to delete these restrictive role assignments using their limited manage_roles permission. Because the API only checks if the requester has control over the target account at the time of deletion, and not whether removing the restriction violates security protocols, the operation succeeds.
The operational impact of this flaw is severe, as it effectively neutralizes the principle of least privilege implemented through role-based access controls. Once the restrictive roles are removed from a server administrator-level account, that account reverts to its full server administrator authority. The attacker can then exploit this temporary window by setting or resetting the password for this elevated account while it holds the unrestricted permissions. Following this modification, the attacker signs in using the new credentials of the compromised administrative account. This sequence grants the attacker complete control over the mail server infrastructure, equivalent to that of a native system administrator. Such access enables unauthorized reading, sending, and deletion of emails, manipulation of user accounts, and potential further compromise of backend systems depending on how hMailServer is integrated with other network services.
This vulnerability aligns closely with ATT&CK technique T1078 Valid Accounts, as the attacker utilizes legitimate credentials to gain initial access, followed by T1098 Account Manipulation, specifically modifying account permissions or roles to escalate privileges. The failure to enforce state-based authorization checks during privilege modification operations highlights a significant gap in the application's security design. To mitigate this risk, immediate updates to hMailServer beyond version 6.3.6 are required if available, as these versions likely contain patches addressing the logic error in the role assignment deletion endpoint. In environments where upgrading is not immediately feasible, administrators should restrict network access to the REST administration API using firewalls or reverse proxies that limit exposure to trusted IP addresses only. Additionally implementing strict monitoring for changes to administrative accounts and reviewing logs for unusual patterns of role modification can help detect exploitation attempts early. It is also recommended to audit existing role assignments to ensure no high-privilege accounts rely solely on restrictive roles without additional safeguards, thereby reducing the attack surface available to users with manage_roles permissions.