ZITADEL CVE-2026-119129

The instance must host at least one application configured with the OAuth 2.0 Device Code grant type - instances without such an application cannot start a device authorization and are not affected. For the one-click vector, the victim must have an active hosted Login V2 session in the same browser and must open the attacker-supplied link (passive user interaction, UI:P); users who sign in only through the hosted Login V1 UI have no reusable Login V2 session and are not affected by this vector. The separate API vector via POST /v2/oidc/device_authorization/{device_authorization_id} bypasses the project access settings 'Only authorized users can authenticate' and 'Authentication is restricted to users from organizations that have been granted access to this project', and also affects custom login UIs built on the OIDC service API; both vectors remain within a single instance. The attacker cannot read the victim's password or second factors and cannot approve a device without the victim opening the link in a browser with an active Login V2 session. No configuration fully closes the gap on unpatched versions; per the vendor, upgrading is the only complete fix, and if the Device Authorization flow is unused, removing the Device Code grant type from all applications prevents both vectors.

This is a genuine high-priority issue for ZITADEL operators, not a high-CVSS-but-low-real-risk case. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) describes a network-reachable flaw of low complexity that an unauthenticated attacker can trigger, requiring only that the victim open a single link (UI:P / passive user interaction). The vulnerable-system impact is high for both confidentiality and integrity (VC:H/VI:H) because the attacker receives the victim's access, ID and optional refresh tokens, and - if the ZITADEL project scope is requested against an administrator - gains administrative control of the organization or instance. The vuln.today Decision label is 'this_week', and the report originates from VulnCheck, indicating elevated but not emergency urgency; teams should remediate within days. No CISA KEV listing is present in the input, and no EPSS score was provided, so widespread-exploitation probability cannot be quantified from the data. No verified working exploit code is referenced - only the vendor GHSA advisory and a VulnCheck advisory. The practical limiter is real: the one-click vector only works against a victim who currently holds an active hosted Login V2 session in the same browser, and only when an application with the Device Code grant type exists on the instance. The API vector (bypassing project access settings) does not need the one-click session and also affects custom login UIs built on the OIDC service API.

An attacker initiates an OAuth 2.0 device authorization for an application that has the Device Code grant type, then sends a signed-in ZITADEL user a link to the Login V2 signed-in page carrying the attacker's user code. When the victim - who has an active Login V2 session - opens the link, the device is approved with no consent prompt and no user-code entry, and the attacker's device receives the victim's tokens with the requested scopes; against an admin this yields organization- or instance-wide control. No verified public exploit code is referenced, but the attack is low-complexity and requires only passive victim interaction.