CVE-2026-31834: Vertical Privilege Escalation in Umbraco CMS User Group Management

Umbraco CMS exposes a Management API to handle administrative backoffice operations. The user management functional area permits delegated administration, allowing restricted users to manage other user accounts. This enables standard users, such as editors, to create and modify lower-privileged accounts without requiring full system administrative access.

The system exhibits an Improper Privilege Management (CWE-269) vulnerability within the user group assignment logic. Missing authorization checks (CWE-862) at the API layer allow a restricted user to assign roles that exceed their own permission level. The backend trusts user-provided group identifiers without validating them against the performing user's authorization context.

Exploitation of this vulnerability allows an attacker with standard user management permissions to escalate their privileges or the privileges of another account to Administrator. This results in complete compromise of the CMS environment, granting the attacker the ability to modify system configurations, access sensitive data, and execute arbitrary code.

The vulnerability originates in the Umbraco Management API endpoint responsible for modifying user group associations. The /umbraco/management/api/v1/user/set-user-groups endpoint accepts a JSON payload containing target user identifiers alongside an array of group aliases or GUIDs. The backend service method UpdateUserGroupsOnUsersAsync processes this request directly.

Prior to the patch, the application failed to contextualize the incoming request with the performing user's identity. The service executed the database update without verifying whether the requested groups possessed permissions exceeding those of the requesting user. The validation boundary existed exclusively within the user interface, which restricted the available dropdown options but failed to enforce these restrictions at the API level.

Because the backend trusted the user-provided list of group IDs implicitly, the system accepted assignments to the "Administrators" group from any account possessing basic user management rights. The architectural flaw involves decoupling the functional permission to manage users from the hierarchical constraint of only assigning user groups equal to or lower than the performing user's own groups.

The remediation efforts across commits 040f27c673f65d8b3d8ebada54733b0fdc774498, 5f389f8bb430844851e6ac02b5c9da02cc304673, and 11a412c0fd89c70af2fa76dd3478a3e8024dfeb2 introduce a centralized authorization utility. The UserGroupAssignmentAuthorization.cs class enforces strict hierarchical boundaries during group assignment, ensuring users can only assign roles they already possess.

The patched code mechanism relies on set operations to compare requested groups against the performing user's groups:

public static IReadOnlyList<string> GetUnauthorizedGroupAssignments(
    IEnumerable<string> performingUserGroupAliases,
    IEnumerable<string> requestedGroupAliases,
    IEnumerable<string> existingGroupAliases)
{
    var performingGroups = performingUserGroupAliases.ToHashSet(StringComparer.InvariantCultureIgnoreCase);
    var existingGroups = existingGroupAliases.ToHashSet(StringComparer.InvariantCultureIgnoreCase);
 
    return requestedGroupAliases
        .Where(alias => existingGroups.Contains(alias) is false && performingGroups.Contains(alias) is false)
        .ToArray();
}

The UpdateUserGroupsUserController requires contextual awareness of the executing user. The patch modifies the controller to inject the current user's key via the IBackOfficeSecurityAccessor interface. The service layer invokes the authorization utility before processing the database transaction. If the requested group alias is absent from the performing user's group list, the transaction is rejected.

This implementation successfully closes the vulnerability by linking the state of the performing user to the assignment logic. The design pattern adheres to the principle of least privilege, preventing vertical movement via role assignment manipulation.

The exploitation phase requires the attacker to possess valid backoffice credentials. The account must be provisioned with functional permissions to access the "Users" section and manage standard accounts. Attackers without these baseline permissions cannot interact with the vulnerable API endpoint.

The attacker initiates a standard user group update via the Umbraco backoffice UI. Using an intercepting proxy, the attacker captures the outbound POST request destined for the /umbraco/management/api/v1/user/set-user-groups endpoint. The attacker halts the request execution to modify the payload.

The attacker alters the intercepted JSON payload, specifically targeting the userGroupIds array. By appending the GUID or alias associated with the "Administrators" group to this array, the attacker crafts a privilege escalation request. The modified request is then forwarded to the server.

The backend API processes the manipulated payload without applying authorization validation. The target account is immediately added to the "Administrators" group, granting the attacker unrestricted administrative access to the CMS environment. The system records the assignment in the database without raising validation errors.

Successful exploitation yields complete control over the Umbraco CMS application. Administrative access allows the attacker to modify website content, execute arbitrary code via template manipulation, and access sensitive data stored within the CMS database. This represents a total loss of confidentiality, integrity, and availability within the CMS context.

The vulnerability receives a CVSS v3.1 base score of 7.2 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). The High Privileges Required (PR:H) metric reflects the necessity for user management permissions to execute the attack. Despite this requirement, the impact scores (C:H/I:H/A:H) demonstrate the severity of the subsequent escalation.

The Exploit Prediction Scoring System (EPSS) assigns a score of 0.00036, placing the vulnerability in the 10.30th percentile. No public exploits or weaponized proofs-of-concept are currently available. This data indicates a low probability of immediate widespread exploitation, though targeted attacks against misconfigured environments remain a threat.

The vendor has released updated versions to address this vulnerability. Organizations utilizing Umbraco CMS must upgrade to versions 16.5.1 or 17.2.2 to implement the necessary authorization controls within the management API. These updates enforce the required validation logic in the backend service layer.

If immediate patching is not feasible, administrators must review all accounts possessing user management permissions. Revoking "Users" section access from non-administrative or untrusted accounts effectively mitigates the attack vector. This temporary workaround restricts access to the vulnerable API endpoint entirely.

Security teams should monitor Umbraco audit logs for unexpected additions to the "Administrators" group. Security Information and Event Management (SIEM) systems can be configured to alert on POST requests to the /set-user-groups endpoint originating from restricted user accounts. Identifying lateral or vertical movement in the logs facilitates rapid incident response.