GHSA-Q3V2-XJ35-9GRX: Unrestricted Configuration Resolution in Umbraco.AI Leads to Sensitive Information Exposure

The Umbraco.AI core integration layer allows administrators to configure integrations with external Large Language Model (LLM) providers like OpenAI, Anthropic, and AWS Bedrock. To simplify credential management and avoid hardcoding secrets in database tables, the package features a dynamic configuration lookup resolver. When a configuration parameter begins with a $ character, the integration layer intercepts this value and attempts to resolve it dynamically from the server host's application settings.

In versions of Umbraco.AI up to and including 1.13.0, this resolver mechanism does not perform any validation on the requested configuration paths. The design acts as an unrestricted reader of the application's global IConfiguration container. This allows high-privileged administrative accounts to request any configuration key in the system, creating an information disclosure vector.

This vulnerability is categorized as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The target attack surface is the Umbraco backoffice administrative interface, specifically the AI connection settings forms. Because the application exposes sensitive system parameters, an administrative attacker can escalate access by discovering infrastructure credentials.

The root cause lies in the overly permissive design of the dynamic configuration parsing engine within the Umbraco.AI core codebase. The system was designed to accept any string prefixed with $ as an alias pointing to the underlying IConfiguration provider. At runtime, the resolver extracts the prefix, parses the remaining path string, and invokes the standard configuration retrieval API without verifying if the path is restricted or if the target attribute is intended to be public.

For instance, when a developer configures an API key reference such as $OpenAI:ApiKey, the system reads the string, splits it by the delimiter :, and accesses _configuration["OpenAI:ApiKey"]. However, because there is no boundary validation, an attacker can input any logical path available within the JSON configurations, environment variables, or secret managers. This includes root-level properties or unrelated branches of the IConfiguration tree.

To trigger the resolution, the attacker must cause the system to evaluate the config setting. This typically occurs during standard operations such as verifying a connection, initiating an AI-driven agent task, or triggering validation schemas. When the system attempts to authenticate against the external provider using the resolved value, the secret is processed and, in many cases, exposed within the resulting application errors or network logs.

The patch release 2026.06.2 introduced major structural changes to the way configuration values are parsed and resolved. In vulnerable versions, there were no restrictive guardrails on keys. In the patched versions (starting with 1.14.0), the system implements a strict default-deny model.

Below is an illustration of the configuration structure change before and after the patch:

// VULNERABLE APPROACH (Any key path could be resolved)
{
  "ApiKey": "$OpenAI:ApiKey",
  "ConnectionStrings": {
    "umbracoDbDSN": "Server=db;Database=umbraco;User Id=sa;Password=secret;"
  }
}

// PATCHED APPROACH (Strict default-deny prefix enforcement)
{
  "ApiKey": "$Umbraco:AI:Secrets:OpenAIApiKey"
}

The underlying C# configuration resolver was updated to validate the requested path against an allowlist. The default allowed prefixes are restricted to:

• Umbraco:AI:Secrets (for highly sensitive credentials)
• Umbraco:AI:Variables (for standard application options)

The dynamic resolver checks the parsed string prefix against AIOptions.AllowedConfigurationKeyPrefixes. If the key does not match these prefixes, the resolver rejects the request and throws a security exception. Additionally, values retrieved from Umbraco:AI:Secrets are only permitted to populate configuration properties explicitly marked as sensitive using metadata decorators (such as IsSensitive).

Exploitation requires the attacker to hold administrative privileges or have direct access to the AI configuration panel in the Umbraco backoffice. This elevated privilege requirement aligns with the CVSS Privileges Required (PR) metric of High. The target server must also run dynamic tests that return the configuration values or show validation feedback that leaks details to the client.

First, the attacker logs into the backoffice and navigates to the AI Connection settings page. The attacker locates a credential field, such as the API Key, and inputs a target key path from the application's configuration tree, prefixed with $. An example target path is $ConnectionStrings:umbracoDbDSN to target the main database connection details.

Second, the attacker saves the settings and triggers a connection test or runs an automated AI task. The backend resolver intercepts the configuration string, extracts ConnectionStrings:umbracoDbDSN, queries the global provider, and injects the raw database connection string into the outgoing connection parameters.

Finally, because the target server (e.g., OpenAI) rejects the database connection string as an invalid API key, the system generates an error. This error message is returned to the backoffice client or written to standard logs, exposing the plaintext database connection string, containing usernames and passwords, to the attacker.

The security impact of this vulnerability is significant, as it enables total confidentiality compromise of all application-level secrets managed by the host server. Although exploitation requires high-privileged access, an administrator is typically not intended to read system-wide infrastructure secrets such as raw database connection parameters, SMTP credentials, or third-party OAuth Client Secrets.

A compromised session with backoffice configuration access can be leveraged to escalate privileges across the wider corporate network. For example, extracting the umbracoDbDSN connection string grants direct read and write access to the underlying database, allowing the attacker to alter user tables, manipulate audit logs, or extract business-critical data.

If the application utilizes Azure Active Directory or other identity providers, the attacker can extract client secrets configured in appsettings.json, potentially gaining unauthorized access to cloud assets. Because the scope remains unchanged, the impact is confined to the immediate system and systems accessible via the stolen credentials.

The primary remediation strategy is to upgrade all installed Umbraco.AI packages and related integration modules to version 1.14.0 or higher. The vendor released a comprehensive patch set in release bundle 2026.06.2 to ensure proper dependency synchronization.

Administrators must also migrate existing dynamic references within appsettings.json or Environment Variables to the newly enforced namespaces. All secrets must be relocated under Umbraco:AI:Secrets and all non-sensitive variables under Umbraco:AI:Variables. Legacy configurations using custom paths will fail to resolve under the default-deny posture unless explicitly allowed.

If legacy configuration paths must be retained temporarily, developers can configure an exception in the application's startup file. By adding custom paths to AIOptions.AllowedConfigurationKeyPrefixes, the resolver will continue to permit those specific paths. However, this configuration is discouraged as it reduces the effectiveness of the patch's defense-in-depth design.