CveMateVulnerability intelligence

Zitadel vulnerabilities, page 3

75 vulnerabilities

Known vulnerabilities in Zitadel products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 1 product.

CVE-2026-105213zitadelzitadel17d ago04-10-2026 13:10

ZITADEL 4.x before 4.17.1 does not check an organization's inactive state during Login V2 authentication, verifying only the individual user's status. Users of a deactivated organization who hold valid credentials, an existing session, or a refresh token can still sign in, create sessions, and obtain or refresh tokens.CVE-2026-105212zitadelzitadel17d ago04-10-2026 13:10

ZITADEL 3.x before 3.4.14 and 4.x before 4.16.2 contains an authentication bypass in the hosted Login V1 and Login V2 UIs that accepts passkey or other authenticator enrollment on identify-only login sessions, before any primary factor is verified. Unauthenticated attackers knowing only a victim's login name can register an attacker-controlled authenticator and log in as that user, bypassing existing passwords and MFA.CVE-2026-105206zitadelzitadel17d ago04-10-2026 13:10

ZITADEL 3.0.0 through 3.4.15 and 4.x before 4.17.3 contains an incorrect authorization flaw in the User Service API, which verifies user.read against the caller's organization rather than the organization owning the target user. An authenticated member holding org-scoped user.read can query GET /v2/users/{userId}/authentication_methods to learn which authentication method types users in other organizations have registered.CVE-2026-105208zitadelzitadel17d ago04-10-2026 13:10

ZITADEL 4.x before 4.17.3 and 3.x through 3.4.15 protects IdP intent tokens with unauthenticated, malleable encryption, allowing authenticated users to tamper with their own token so it is accepted for another user's external login intent. An attacker who predicts a victim's in-flight intent identifier and wins a timing race can call /v2/idp_intents or /v2/sessions to steal the victim's IdP tokens or hijack their session.CVE-2026-105211zitadelzitadel17d ago04-10-2026 13:10

ZITADEL before 4.17.1 contains an authentication bypass vulnerability in Login V2 that allows unauthenticated attackers to take over accounts by obtaining OTP codes via the returnCode delivery type. Attackers knowing a login name of a victim with OTP-Email and OTP-SMS enrolled can read both codes from server-action responses to gain MFA-authenticated sessions, including administrator takeover.CVE-2026-55670chainguardzitadel-3+23mo ago10-07-2026 17:15

ZITADEL is an open source identity management platform. Prior to 4.15.1, ZITADEL's event store validation can retain the original resource owner for a deleted user identifier, causing a later user recreated with the same identifier in another organization to be provisioned under the original organization and exposed to that organization's administrator. This issue is fixed in version 4.15.2.CVE-2026-55669github.com/zitadelzitadel+13mo ago10-07-2026 16:58

ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL's external JWT Identity Provider validates a token's signature and issuer (iss) but not the audience (aud) claim, allowing a validly signed token from a trusted issuer for another relying party to be accepted by ZITADEL. This issue is fixed in versions 3.4.12 and 4.15.2.CVE-2026-55672github.com/zitadelzitadel+13mo ago10-07-2026 17:19

ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL'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.CVE-2026-55671chainguardzitadel-3+23mo ago10-07-2026 17:17

ZITADEL is an open source identity management platform. From 4.0.0-rc.1 through 4.15.1, ZITADEL's HTTP notification channels, OIDC BackChannel Logout, and SAML metadata URL fetches do not consistently validate user-defined URLs against protected denylist handling, allowing server-side requests to loopback, internal IP, link-local, or redirected endpoints through DNS rebinding, redirects, or protocol downgrades. This issue is fixed in version 4.15.2.CVE-2026-76081chainguardzitadel-3+21mo ago14-09-2026 21:30

ZITADEL is an open source identity management platform. Prior to version 4.16.0, a bug in how ZITADEL updates permissions when multiple project roles are deleted at the same time can cause some user permissions to be missed. This issue specifically affects User Grants on Granted Projects (projects shared between different organizations), potentially allowing users to keep access rights that were supposed to be completely removed. This issue has been fully resolved in version 4.16.0. There are no configuration workarounds. Upgrading to a patched version is the only way to trigger the automatic cleanup migration. Those who cannot upgrade immediately should manually review user permissions specifically for Granted Projects where multiple roles were recently deleted.CVE-2026-56664github.com/zitadelzitadel+13mo ago10-07-2026 17:21

ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL's external JWT Identity Provider validation in internal/idp/providers/jwt/session.go skips the maximum token age freshness check when an incoming token omits the iat claim, allowing arbitrarily old tokens from a trusted issuer to pass authentication. This issue is fixed in versions 3.4.12 and 4.15.2.CVE-2026-56667chainguardzitadel-3+13mo ago10-07-2026 17:25

ZITADEL is an open source identity management platform. Prior to 4.15.3, ZITADEL Login V2 OIDC and SAML FailedPrecondition error paths return loginSettings.defaultRedirectUri to router.push without applying the isSafeRedirectUri check, allowing an organization or instance administrator to store a javascript or data URI that can execute in a user's browser when an affected login error path is reached. This issue is fixed in version 4.15.3.CVE-2026-56666chainguardzitadel-3+23mo ago10-07-2026 17:37

ZITADEL is an open source identity management platform. Prior to 4.15.3, ZITADEL's external identity provider handler checks that the local user's email is verified but does not verify that the external IdP confirmed ownership of the same email before auto-linking by email, allowing a permissive provider account with a victim email address to be linked to the victim's local account. This issue is fixed in version 4.15.3.CVE-2026-56665github.com/zitadelzitadel+13mo ago10-07-2026 17:22

ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL is an open source identity management platform. From 3.0.0-rc.1 through 3.4.11 and from 4.0.0-rc.1 through 4.15.1, ZITADEL's external JWT Identity Provider validation in internal/idp/providers/jwt/session.go skips expiration handling when an incoming token omits the exp claim, allowing a token from a trusted issuer to be treated as valid without an automatic expiration window. This issue is fixed in versions 3.4.12 and 4.15.2.CVE-2026-56668chainguardzitadel-3+23mo ago10-07-2026 17:46

ZITADEL is an open source identity management platform. Prior to 4.15.3, ZITADEL's OAuth2 Token Exchange endpoint for urn:ietf:params:oauth:grant-type:token-exchange does not verify that the subject token belongs to the requesting client or that requested scopes remain within the original token's scopes, allowing a low-privilege token to be exchanged for elevated permissions at another application. This issue is fixed in version 4.15.3.CVE-2026-29067github.com/zitadelzitadel+27mo ago07-03-2026 15:12

ZITADEL is an open source identity management platform. From version 4.0.0-rc.1 to 4.7.0, a potential vulnerability exists in ZITADEL's password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user. This issue has been patched in version 4.7.1.CVE-2026-29193github.com/zitadelzitadel+27mo ago07-03-2026 15:11

ZITADEL is an open source identity management platform. From version 4.0.0 to 4.12.0, a vulnerability in Zitadel's login V2 UI allowed users to bypass login behavior and security policies and self-register new accounts or sign in using password even if corresponding options were disabled in their organizaton. This issue has been patched in version 4.12.1.CVE-2026-29192github.com/zitadelzitadel+27mo ago07-03-2026 15:09

ZITADEL is an open source identity management platform. From version 4.0.0 to 4.11.1, a vulnerability in Zitadel's login V2 interface was discovered that allowed a possible account takeover via Default URI Redirect. This issue has been patched in version 4.12.0.CVE-2026-29191github.com/zitadelzitadel+27mo ago07-03-2026 15:07

ZITADEL is an open source identity management platform. From version 4.0.0 to 4.11.1, a vulnerability in Zitadel's login V2 interface was discovered that allowed a possible account takeover via XSS in /saml-post Endpoint. This issue has been patched in version 4.12.0.CVE-2026-27840github.com/zitadelzitadel+17mo ago26-02-2026 00:27

ZITADEL is an open source identity management platform. Starting in version 2.31.0 and prior to versions 3.4.7 and 4.11.0, opaque OIDC access tokens in the v2 format truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID. V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token. The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. The patch in versions 4.11.0 and 3.4.7 resolves the issue by verifying the `user_id` from the token against the session data from the database. No known workarounds are available.