Summary
ZITADEL Login V2 does not sufficiently verify authorization when approving OAuth 2.0 device requests. An attacker may send a signed-in user a link containing the attacker's device code, causing the victim's session to approve it and allowing the attacker to obtain tokens associated with the victim.
ZITADEL Login V2 does not sufficiently verify authorization when approving OAuth 2.0 device requests. An attacker may send a signed-in user a link containing the attacker's device code, causing the victim's session to approve it and allowing the attacker to obtain tokens associated with the victim.
Affected context
The issue occurs in ZITADEL deployments using Login V2 and the OAuth 2.0 device authorization flow. Risk is present when a victim has an active authenticated session, the device authorization endpoint accepts the supplied code, and authorization or project-access checks are not consistently enforced before approval.
The issue occurs in ZITADEL deployments using Login V2 and the OAuth 2.0 device authorization flow. Risk is present when a victim has an active authenticated session, the device authorization endpoint accepts the supplied code, and authorization or project-access checks are not consistently enforced before approval.
Exploit preconditions
- Attack surface: Login V2 device authorization and OIDC device authorization
endpoints
- Required access: The victim must have an active authenticated ZITADEL
session; the attacker does not necessarily need access to that session
- Trigger point: The victim follows an attacker-controlled link or otherwise
submits an attacker-chosen device code while signed in
- Why exploitation is possible: The application associates approval with the
existing session without adequately verifying that the user intentionally
authorized the displayed device request or that the request satisfies project
access controls
- Attack surface: Login V2 device authorization and OIDC device authorization
endpoints
- Required access: The victim must have an active authenticated ZITADEL
session; the attacker does not necessarily need access to that session
- Trigger point: The victim follows an attacker-controlled link or otherwise
submits an attacker-chosen device code while signed in
- Why exploitation is possible: The application associates approval with the
existing session without adequately verifying that the user intentionally
authorized the displayed device request or that the request satisfies project
access controls
Why this happens
The underlying defect is an authorization decision made without sufficient validation of the requested device authorization and the user's intended consent. This represents CWE-862, Missing Authorization: a protected action is reachable without a complete permission check tied to the relevant resource, client, project, and user intent. In this case, an authenticated session is treated as sufficient to approve a device request, even when the request was initiated by another party or falls outside configured project access rules.
The underlying defect is an authorization decision made without sufficient validation of the requested device authorization and the user's intended consent. This represents CWE-862, Missing Authorization: a protected action is reachable without a complete permission check tied to the relevant resource, client, project, and user intent. In this case, an authenticated session is treated as sufficient to approve a device request, even when the request was initiated by another party or falls outside configured project access rules.
Potential impact
- An attacker may obtain OAuth or OIDC tokens issued through the victim's session
- The attacker could gain unauthorized access to resources available to the victim
- Project-level access restrictions may be bypassed
- Account data or connected applications could be accessed or modified
- The incident could undermine user consent and auditability for device authorization
- An attacker may obtain OAuth or OIDC tokens issued through the victim's session
- The attacker could gain unauthorized access to resources available to the victim
- Project-level access restrictions may be bypassed
- Account data or connected applications could be accessed or modified
- The incident could undermine user consent and auditability for device authorization
General mitigation guidance
Mitigation generally focuses on binding every device-authorization approval to the exact request, client, project, and authenticated user, while requiring explicit and unambiguous consent. Authorization checks should be enforced server-side before token issuance rather than relying on the presence of a valid session or user-supplied codes. Device codes should be treated as untrusted, single-use, short-lived values, and secure-by-default flows should display sufficient request context for informed approval. Project access policies should be evaluated consistently across all OIDC and device authorization paths, with least-privilege scopes and strong session protections limiting the effect of an approval mistake.
Mitigation generally focuses on binding every device-authorization approval to the exact request, client, project, and authenticated user, while requiring explicit and unambiguous consent. Authorization checks should be enforced server-side before token issuance rather than relying on the presence of a valid session or user-supplied codes. Device codes should be treated as untrusted, single-use, short-lived values, and secure-by-default flows should display sufficient request context for informed approval. Project access policies should be evaluated consistently across all OIDC and device authorization paths, with least-privilege scopes and strong session protections limiting the effect of an approval mistake.
How teams detect issues like this
Detection can include static and dynamic analysis for approval handlers that accept device or authorization codes without resource-owner, client, project, scope, and consent checks. Code review should look for authorization decisions based solely on authentication state, user-controlled identifiers, or inconsistent policy enforcement between browser and API routes. Security tests can exercise cross-user device-code substitution, project-access denial cases, replay attempts, and mismatched client identifiers. Logging and policy monitoring should record approval context, client, project, scopes, and session identity, while automated review tools may help flag missing authorization checks in sensitive handlers.
Detection can include static and dynamic analysis for approval handlers that accept device or authorization codes without resource-owner, client, project, scope, and consent checks. Code review should look for authorization decisions based solely on authentication state, user-controlled identifiers, or inconsistent policy enforcement between browser and API routes. Security tests can exercise cross-user device-code substitution, project-access denial cases, replay attempts, and mismatched client identifiers. Logging and policy monitoring should record approval context, client, project, scopes, and session identity, while automated review tools may help flag missing authorization checks in sensitive handlers.
