Unauthenticated Data Exposure via Broken Access Control in Umbraco Engage

Umbraco Engage, a marketing automation and business intelligence extension for the Umbraco CMS, contains a high-severity Broken Access Control vulnerability. The flaw exists within the Umbraco.Engage.Forms package and general Engage API layers. These components are responsible for handling marketing analytics, tracking user engagement, and processing form submissions.

The core issue is the exposure of internal API endpoints to the public network without adequate access controls. While these endpoints typically serve legitimate administrative or headless frontend functions, they lack the necessary authentication middleware to verify the requester's identity. Furthermore, they fail to implement attribute-based authorization, meaning the server processes requests from any source as if they were trusted.

This oversight classifies the vulnerability under CWE-284 (Improper Access Control) and CWE-306 (Missing Authentication for Critical Function). The impact is strictly limited to confidentiality; the integrity of the data and the availability of the service remain unaffected. However, the sensitivity of the exposed data—ranging from marketing strategies to customer form inputs—presents a substantial risk to organizations relying on Umbraco for digital marketing operations.

The vulnerability stems from a failure to enforce security policies at the controller level within the ASP.NET Core application structure of Umbraco Engage. In the affected versions, specific API controllers responsible for retrieving form data and analytics records were deployed without the [Authorize] attribute or equivalent policy-based security filters.

In a secure Umbraco implementation, backoffice API endpoints are protected by the Umbraco Backoffice authentication scheme, which ensures that only logged-in administrators or editors can access administrative APIs. In this instance, the developers likely intended for the endpoints to be internal or restricted but omitted the specific middleware registration required to reject anonymous HTTP requests.

Compounding this missing authentication is the use of predictable resource identifiers. The endpoints accept input parameters—often sequential integers or standard UUIDs—to identify specific records (e.g., ?id=1001). Because the application implicitly trusts the request, it performs the database lookup and returns the record without verifying if the anonymous user has ownership or permission to view that specific object. This combination of missing authentication and predictable IDs creates a classic Insecure Direct Object Reference (IDOR) scenario (CWE-639).

The flaw resides in how the API controllers define their accessibility. Below is a conceptual representation of the vulnerable code pattern versus the secure implementation found in the patched versions.

Vulnerable Implementation (Conceptual):

The controller inherits from a standard base class but fails to apply security attributes. The GetSubmission action accepts an id and returns data directly.

// VULNERABLE CONTROLLER PATTERN
[Route("umbraco/engage/api/forms")]
public class EngageFormsApiController : Controller
{
    // Lacks [Authorize] attribute
    // Accessible by any unauthenticated client
    [HttpGet("getsubmission")]
    public IActionResult GetSubmission(int id)
    {
        // No check to see if User has access to 'id'
        var submission = _repository.GetById(id);
        if (submission == null) return NotFound();
        
        // Returns sensitive JSON data directly
        return Ok(submission);
    }
}

Patched Implementation:

The fix involves applying the [Authorize] attribute, specifically enforcing the Umbraco Backoffice policy. This ensures the request pipeline validates the session cookie or bearer token before the action method is ever invoked.

// SECURE CONTROLLER PATTERN
[Route("umbraco/engage/api/forms")]
// Enforces authentication. Only backoffice users can access.
[Authorize(Policy = "UmbracoBackoffice")]
public class EngageFormsApiController : Controller
{
    [HttpGet("getsubmission")]
    public IActionResult GetSubmission(int id)
    {
        // Request is now pre-validated by middleware.
        // Additional checks for specific permissions (e.g., Content Read) 
        // may also be implemented here.
        var submission = _repository.GetById(id);
        return Ok(submission);
    }
}

The remediation effectively shifts the security responsibility to the framework's middleware, preventing the execution of the business logic for unauthorized requests.

Exploitation of CVE-2026-27449 is trivial due to the lack of complex prerequisites. An attacker requires only network access to the Umbraco instance and knowledge of the endpoint structure.

Step 1: Endpoint Enumeration The attacker identifies the target server runs Umbraco Engage. They probe for common Engage API paths. Since the vulnerability is in a standard package, the paths are consistent across installations (e.g., /umbraco/engage/api/...).

Step 2: ID Manipulation The attacker sends a GET request to a vulnerable endpoint, supplying a guessed ID.

curl -X GET "https://target.com/umbraco/engage/api/forms/details?id=500" -H "Accept: application/json"

Step 3: Data Exfiltration If the ID exists, the server returns a 200 OK response with a JSON payload containing the form submission or analytics data. The attacker then automates this process using a script (e.g., Python or Burp Intruder) to iterate through a range of IDs (1 to 10000), scraping the entire database of submissions without triggering standard login failure alerts.

The primary impact of this vulnerability is a high-severity loss of confidentiality. The specific nature of the data exposed depends on how the organization utilizes Umbraco Engage, but the potential scope is significant.

Data Types at Risk:

• Form Submissions: Contact forms often contain PII (names, emails, phone numbers) and potentially sensitive inquiries.
• Analytics Data: Business intelligence regarding user behavior, conversion rates, and campaign performance.
• Customer Profiles: Aggregated data used for marketing segmentation.

CVSS v3.1 Breakdown (7.5 High):

• AV:N (Network): Exploitable remotely over the internet.
• AC:L (Low): No specialized conditions required.
• PR:N (None): No authentication credentials needed.
• C:H (High): Total disclosure of the information protected by the affected component.

Although Integrity and Availability are not directly impacted, the reputational damage and regulatory compliance violations (GDPR, CCPA) resulting from the leak of user PII constitute a critical business risk.