Mar 11, 2026·5 min read·3 visits
Authenticated Umbraco backoffice users can bypass permissions to read or modify domain and notification settings of restricted content nodes due to missing resource-level authorization checks in the Management API controllers.
Umbraco CMS suffers from a Broken Object-Level Authorization (BOLA) vulnerability within its Management API. Authenticated backoffice users can bypass node-level boundary restrictions to view and modify domain and notification configurations for arbitrary content nodes. The flaw is rooted in missing resource-level authorization checks in specific API controllers.
Umbraco CMS relies on a granular permissions model for backoffice users, restricting administrative access to specific "Start Nodes" within the content tree. The Management API provides endpoints for modifying content configurations, including domain routing, language cultures, and notifications.
CVE-2026-31832 identifies a Broken Object-Level Authorization (BOLA) vulnerability within specific endpoints of this API. The flaw allows an authenticated user to bypass their assigned Start Node boundaries and interact with any content node by supplying its GUID in the request path.
The vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-285 (Improper Authorization). It exposes the application to unauthorized state modification and data exposure, specifically regarding hostnames and notification routing.
The structural root cause of CVE-2026-31832 is the failure to perform secondary, resource-level authorization checks within the controller layer. The application strictly verified that the incoming request contained a valid backoffice session, but omitted validation against the specific object being requested.
Controllers such as DomainsController, UpdateDomainsController, and UpdateNotificationsController accept a target Guid id parameter representing a specific content node. The vulnerable implementations passed this user-supplied GUID directly to the underlying IDomainService and INotificationService without querying the authorization matrix.
In a secure implementation, the controller must assert that the current user context holds specific action permissions against the target identifier. The omission of this verification effectively flattened the authorization hierarchy, granting any authenticated backoffice user global access to domain and notification management endpoints.
An examination of the patch reveals the introduction of explicit resource-bound authorization requirements. Prior to the fix, the UpdateDomainsController invoked the domain service directly based solely on endpoint routing constraints and general authentication filters.
// VULNERABLE IMPLEMENTATION
[HttpPut("{id:guid}/domains")]
public async Task<IActionResult> Update(CancellationToken cancellationToken, Guid id, UpdateDomainsRequestModel updateModel)
{
DomainsUpdateModel domainsUpdateModel = _umbracoMapper.Map<DomainsUpdateModel>(updateModel)!;
// Execution proceeds without checking if the user has rights to 'id'
Attempt<DomainUpdateResult, DomainOperationStatus> result = await _domainService.UpdateDomainsAsync(id, domainsUpdateModel);
}The patched implementation injects the IAuthorizationService and enforces a policy check before processing the request payload. The system now validates the User claims against the ContentPermissionByResource policy, specifically demanding the ActionAssignDomain.ActionLetter permission for the supplied object identifier.
// PATCHED IMPLEMENTATION
[HttpPut("{id:guid}/domains")]
public async Task<IActionResult> Update(CancellationToken cancellationToken, Guid id, UpdateDomainsRequestModel updateModel)
{
AuthorizationResult authorizationResult = await _authorizationService.AuthorizeResourceAsync(
User,
ContentPermissionResource.WithKeys(ActionAssignDomain.ActionLetter, id),
AuthorizationPolicies.ContentPermissionByResource);
if (!authorizationResult.Succeeded)
{
return Forbidden();
}
DomainsUpdateModel domainsUpdateModel = _umbracoMapper.Map<DomainsUpdateModel>(updateModel)!;
Attempt<DomainUpdateResult, DomainOperationStatus> result = await _domainService.UpdateDomainsAsync(id, domainsUpdateModel);
}Exploitation requires the attacker to possess an active, authenticated session within the Umbraco backoffice. The attacker operates with a low-privileged account, such as an editor restricted to a specific branch of the content tree.
The adversary first obtains the GUID of a target node outside their permitted boundaries. This identifier can often be enumerated, extracted from client-side application state, or harvested from other authenticated API responses that leak associated node GUIDs.
The attacker crafts a direct HTTP PUT request to /umbraco/management/api/v1/document/{id}/domains, substituting {id} with the target GUID. By supplying a modified UpdateDomainsRequestModel payload, the attacker successfully overwrites the domain routing rules for the victim node, bypassing the interface-level restrictions that normally hide these controls.
The primary impact of this BOLA vulnerability is unauthorized data modification and potential service disruption. A malicious backoffice user can alter the hostname bindings of critical web pages, effectively redirecting traffic or causing denial-of-service conditions for specific content branches.
While the CVSS v3.1 base score is 5.4, the practical severity depends heavily on the organizational reliance on granular permissions. Environments that employ zero-trust principles within the CMS and host mutually untrusted editorial teams on the same instance face a higher operational risk.
The vulnerability does not expose direct arbitrary code execution or underlying operating system access. Altering notification configurations allows an attacker to intercept or suppress system alerts related to the targeted content nodes.
The absolute mitigation for CVE-2026-31832 is upgrading the Umbraco CMS installation to a patched release. Administrators must deploy version 16.5.1 or 17.2.2, which introduce the required resource-level authorization checks across the Management API controllers.
If immediate patching is not feasible, security engineers can attempt to deploy Web Application Firewall (WAF) rules to inspect requests to /umbraco/management/api/v1/document/*/domains. Distinguishing between legitimate and unauthorized requests at the WAF level is difficult without deep integration into the CMS session state, making this an incomplete temporary measure.
Organizations should conduct an audit of their backoffice user base to verify authorization assignments. Removing unnecessary accounts and consolidating "Start Node" assignments reduces the overall attack surface available to internal threat actors prior to patch application.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L| Product | Affected Versions | Fixed Version |
|---|---|---|
Umbraco CMS Umbraco | 14.0.0 - < 16.5.1 | 16.5.1 |
Umbraco CMS Umbraco | 17.0.0 - < 17.2.2 | 17.2.2 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-639 (Authorization Bypass Through User-Controlled Key) |
| Attack Vector | Network (API Request) |
| Privileges Required | Low (Authenticated Backoffice User) |
| CVSS v3.1 Score | 5.4 (Medium) |
| Confidentiality Impact | None |
| Integrity Impact | Low |
| Availability Impact | Low |
| Exploit Status | Proof of Concept |
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.