hMailServer CVE-2026-114475

Requires an already-valid credential confined to named domains - specifically a full-scope REST API key issued for named domains, or a serveradmin account assigned a domain list - which holds the manage_roles permission; the attacker invokes the REST create, update, or delete custom-role routes, and because those routes name no domain the authorization gate does not refuse them to the confined credential. Exploitation is meaningful only in a MULTI-TENANT deployment where custom roles are assigned to accounts across OTHER domains than the attacker's; a single-domain/single-tenant install cannot be affected cross-tenant. Limiting factors: authentication is mandatory (PR:L, no anonymous access), the affected versions are 6.3.4 through 6.3.6 (fixed in 6.3.7), and the damage is explicitly bounded - custom roles cannot hold administer_server, administer_domain, or manage_roles, so the confined credential cannot promote itself or anyone to server administrator.

This is a genuine but moderate, authorization-layer (CWE-862) flaw in hMailServer's REST role-management routes, best understood as a multi-tenant broken-access-control issue rather than a classic remote-code or data-theft bug. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) is internally consistent with the description: exploitation is network-reachable (the REST API) but requires an already-valid, low-privileged credential (PR:L - an authenticated user, API key, or serveradmin confined to named domains), and the sole impact is integrity (I:H) - the attacker can rewrite, create, or delete custom roles belonging to OTHER tenants/domains, with no confidentiality (C:N) or availability (A:N) rating. The 6.5 Medium score is appropriate and not inflated: the attacker must first hold a legitimate confined credential, and the description explicitly bounds the damage - a custom role may not hold administer_server, administer_domain, or manage_roles, so this cannot be used for direct privilege escalation to full server administrator. No EPSS score, KEV listing, or POC was provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the signals that are present (Medium CVSS, integrity-only, requires authentication and a multi-tenant deployment) all point to a real priority for hosting providers running hMailServer as a multi-tenant mail platform, but a lower priority for single-tenant/single-domain installations where the cross-domain condition cannot be met. No SSVC decision data was supplied. The one point to verify: the practical blast radius (one tenant silently granting its own role full control over another tenant's mailbox permissions and settings) can be more operationally serious than the 6.5 suggests in a shared-hosting context.

In a shared-hosting hMailServer 6.3.4-6.3.6 deployment, a tenant administrator holding a credential or full-scope API key confined to their own named domains calls the REST create/update/delete role routes, which the authorization gate fails to restrict to the credential's domain scope. The attacker rewrites a custom role assigned to a different tenant - granting that role every permission over the victim tenant's mailboxes and settings, or stripping permissions it needs. No public exploit code was identified in the provided intelligence; exploitation requires an already-authenticated, domain-confined credential and a network path to the REST API.