Mar 11, 2026·5 min read·28 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.
The Netty-based HTTP Client in the Micronaut framework fails to enforce a maximum redirect ceiling by default when processing HTTP responses. This permits remote, attacker-controlled servers to trigger continuous, infinite redirect loops. The resulting recursion causes high CPU utilization, thread starvation, and potential memory exhaustion, inducing a Denial of Service (DoS) state in client-side applications.
An information disclosure vulnerability exists in the Micronaut Framework's HTTP client components. The client fails to clear sensitive authorization headers and cookies when following redirects across different origins. If an application using the vulnerable client communicates with an endpoint that issues a redirect to an external host, the client will forward the original credentials, leading to potential token theft and session hijacking.
GHSA-52vm-mxx8-f227 is a dual-vector security flaw in phantom-audio (<= 1.3.0). The vulnerability allows arbitrary file writes due to unconfined Model Context Protocol (MCP) tool paths when the PHANTOM_OUTPUT_DIR environment variable is not defined. Concurrently, the platform lacks validation controls during the decompression of highly compressed audio files, resulting in resource-exhaustion denial of service and downstream parsing vulnerability exposure.
An authenticated path traversal and arbitrary local file read vulnerability exists in Craft CMS versions 4.x up to 4.17.6 within the assets/icon endpoint and Assets helper classes. By exploiting this vulnerability, an authenticated user can traverse directories and read arbitrary .svg files on the server's filesystem, or execute Stored Cross-Site Scripting (XSS) if they can upload a malicious SVG.
CVE-2026-56382 is a high-severity remote code execution vulnerability in Craft CMS versions 5.5.0 through 5.9.13. The vulnerability exists within the FieldsController::actionRenderCardPreview() method due to a lack of sanitization of the user-supplied fieldLayoutConfig configuration array, permitting authenticated administrators to register arbitrary PHP callbacks using Yii2 event handler injection mechanisms. This issue has been fully remediated in version 5.9.14.
An insecure direct object reference (IDOR) and missing authorization validation check in the Gittensory REST API and Model Context Protocol (MCP) server allowed authenticated users to query arbitrary miner profiles, exposing sensitive cryptographic hotkeys and daily financial/economic yields.