https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 02:18:09 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-335726 EUVD-2026-335726 https://cve.radiocsirt.org/vuln/euvd-2026-335726 https://cve.radiocsirt.org/vuln/fkie_cve-2026-55672 <p>ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL&#39;s OAuth2 and OIDC CodeExchange, RefreshToken, and device token flows fail to verify that the requesting client matches the client that initiated the authorization flow, allowing intercepted grants or refresh tokens to be exchanged under a different client. This issue is fixed in versions 3.4.12 and 4.15.2.</p> <p>ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL&#39;s OAuth2 and OIDC CodeExchange, RefreshToken, and device token flows fail to verify that the requesting client matches the client that initiated the authorization flow, allowing intercepted grants or refresh tokens to be exchanged under a different client. This issue is fixed in versions 3.4.12 and 4.15.2.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-55672 https://cve.radiocsirt.org/vuln/ghsa-xqxv-4jc2-x56x <p><strong>Affected:</strong> Go: github.com/zitadel/zitadel</p> <p>### Summary</p> <p>Zitadel&#39;s OAuth2 / OIDC `CodeExchange` and `RefreshToken` implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.</p> <p>### Impact</p> <p>This flaw creates potential vulnerabilities in two main authentication phases, **provided specific external preconditions are met**:</p> <p>* **Authorization Code Injection:** An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (`ClientB`) registered on the same Zitadel instance. Zitadel will authenticate `ClientB` and issue tokens for the victim user without verifying the client binding. * **Refresh Token Cross-Use:** An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token&#39;s format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client. * Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client con…</p> <p><strong>Affected:</strong> Go: github.com/zitadel/zitadel</p> <p>### Summary</p> <p>Zitadel&#39;s OAuth2 / OIDC `CodeExchange` and `RefreshToken` implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.</p> <p>### Impact</p> <p>This flaw creates potential vulnerabilities in two main authentication phases, **provided specific external preconditions are met**:</p> <p>* **Authorization Code Injection:** An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (`ClientB`) registered on the same Zitadel instance. Zitadel will authenticate `ClientB` and issue tokens for the victim user without verifying the client binding. * **Refresh Token Cross-Use:** An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token&#39;s format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client. * Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client con…</p> https://cve.radiocsirt.org/vuln/ghsa-xqxv-4jc2-x56x