Summary
Umbraco CMS contains an authentication bypass involving attacker-controlled OAuth redirect URIs that can be registered through Host header poisoning. An unauthenticated attacker may abuse the flow to capture authorization codes from signed-in users, hijack back-office sessions, and potentially execute code through Razor templates.
Umbraco CMS contains an authentication bypass involving attacker-controlled OAuth redirect URIs that can be registered through Host header poisoning. An unauthenticated attacker may abuse the flow to capture authorization codes from signed-in users, hijack back-office sessions, and potentially execute code through Razor templates.
Affected context
The issue affects Umbraco CMS deployments using the vulnerable OAuth authorization flow and versions before the relevant security fixes. Risk increases when the application derives redirect URI values from an untrusted Host header, accepts externally supplied authorization links, and permits back-office sessions or authorization codes to be redeemed without sufficiently strict redirect and client validation.
The issue affects Umbraco CMS deployments using the vulnerable OAuth authorization flow and versions before the relevant security fixes. Risk increases when the application derives redirect URI values from an untrusted Host header, accepts externally supplied authorization links, and permits back-office sessions or authorization codes to be redeemed without sufficiently strict redirect and client validation.
Exploit preconditions
- Attack surface: Umbraco CMS OAuth authorization and back-office authentication endpoints
- Required access: No authenticated access is required to influence the vulnerable redirect registration behavior; user interaction is generally needed to follow a crafted authorization link
- Trigger point: OAuth authorization requests using a form-post response mode and subsequent code redemption
- Why exploitation is possible: Host-derived redirect URI handling can allow an attacker-controlled destination to receive authorization material intended for a legitimate back-office session
- Attack surface: Umbraco CMS OAuth authorization and back-office authentication endpoints
- Required access: No authenticated access is required to influence the vulnerable redirect registration behavior; user interaction is generally needed to follow a crafted authorization link
- Trigger point: OAuth authorization requests using a form-post response mode and subsequent code redemption
- Why exploitation is possible: Host-derived redirect URI handling can allow an attacker-controlled destination to receive authorization material intended for a legitimate back-office session
Why this happens
The underlying issue is insufficient validation and trust of the HTTP Host header when constructing or registering OAuth redirect URIs. This creates an open redirect and OAuth flow integrity weakness mapped to CWE-601: URL Redirection to Untrusted Site, allowing authorization responses to be routed to an attacker-controlled location. When redirect destinations, authorization codes, and client authentication are not bound to a trusted origin and narrowly registered client configuration, captured credentials or codes may be used to impersonate privileged users.
The underlying issue is insufficient validation and trust of the HTTP Host header when constructing or registering OAuth redirect URIs. This creates an open redirect and OAuth flow integrity weakness mapped to CWE-601: URL Redirection to Untrusted Site, allowing authorization responses to be routed to an attacker-controlled location. When redirect destinations, authorization codes, and client authentication are not bound to a trusted origin and narrowly registered client configuration, captured credentials or codes may be used to impersonate privileged users.
Potential impact
- An attacker could capture OAuth authorization codes or related authentication responses
- Back-office sessions could be hijacked
- Privileged administrative actions could be performed
- Content, configuration, or user data could be modified
- Server-side code execution through permitted Razor template functionality may occur
- The CMS instance could be used to affect connected systems or downstream users
- An attacker could capture OAuth authorization codes or related authentication responses
- Back-office sessions could be hijacked
- Privileged administrative actions could be performed
- Content, configuration, or user data could be modified
- Server-side code execution through permitted Razor template functionality may occur
- The CMS instance could be used to affect connected systems or downstream users
General mitigation guidance
Mitigation generally focuses on removing Host header trust from security-sensitive URL construction and enforcing strict OAuth redirect validation.
Common defensive patterns include:
- Allowlisting canonical application origins and exact redirect URIs
- Ignoring untrusted Host and forwarded-host values for authorization decisions
- Binding authorization codes to the intended client, redirect URI, and transaction
- Enforcing secure client authentication and short-lived, single-use authorization codes
- Separating administrative authentication flows from user-controlled URL inputs
- Restricting Razor or other server-side template execution capabilities
- Running the CMS and administrative services with least privilege
- Applying trusted proxy configuration and rejecting unexpected host values
Mitigation generally focuses on removing Host header trust from security-sensitive URL construction and enforcing strict OAuth redirect validation.
Common defensive patterns include:
- Allowlisting canonical application origins and exact redirect URIs
- Ignoring untrusted Host and forwarded-host values for authorization decisions
- Binding authorization codes to the intended client, redirect URI, and transaction
- Enforcing secure client authentication and short-lived, single-use authorization codes
- Separating administrative authentication flows from user-controlled URL inputs
- Restricting Razor or other server-side template execution capabilities
- Running the CMS and administrative services with least privilege
- Applying trusted proxy configuration and rejecting unexpected host values
How teams detect issues like this
Organizations can look for:
- Static analysis findings where Host or forwarded-host headers influence redirect URI construction
- Code review signals involving OAuth redirects assembled from request headers
- Authorization endpoints that accept redirect destinations without exact allowlist comparison
- Logs showing unexpected hosts, external redirect targets, repeated authorization-code failures, or unusual back-office sign-ins
- Policy checks requiring canonical-origin configuration and secure OAuth client registration
- Automated application testing that verifies redirect, state, code binding, and client-authentication behavior
Organizations can look for:
- Static analysis findings where Host or forwarded-host headers influence redirect URI construction
- Code review signals involving OAuth redirects assembled from request headers
- Authorization endpoints that accept redirect destinations without exact allowlist comparison
- Logs showing unexpected hosts, external redirect targets, repeated authorization-code failures, or unusual back-office sign-ins
- Policy checks requiring canonical-origin configuration and secure OAuth client registration
- Automated application testing that verifies redirect, state, code binding, and client-authentication behavior
