Skip to main content
Vulnerability Database/CVE-2026-105213

CVE-2026-105213: ZITADEL Authentication Bypass Vulnerability

CVE-2026-105213 is an authentication bypass flaw in ZITADEL 4.x that allows users from deactivated organizations to maintain access through valid credentials or tokens. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-105213 Overview

CVE-2026-105213 is an authentication bypass vulnerability in ZITADEL identity and access management affecting versions 4.x prior to 4.17.1. The Login V2 flow verifies only the individual user's active status and fails to check whether the parent organization is deactivated. Users belonging to a deactivated organization can still authenticate, create new sessions, and obtain or refresh OAuth tokens if they hold valid credentials, an existing session, or a refresh token. This flaw weakens a core organizational lifecycle control that administrators rely on to immediately revoke access for an entire tenant.

Critical Impact

Attackers with credentials or refresh tokens tied to a deactivated organization retain full authenticated access, defeating organization-level offboarding and tenant suspension controls.

Affected Products

  • ZITADEL 4.x prior to version 4.17.1
  • Deployments using the Login V2 authentication flow
  • Any ZITADEL tenant relying on organization deactivation as an access revocation control

Discovery Timeline

  • 2026-10-04 - CVE-2026-105213 published to the National Vulnerability Database
  • 2026-10-05 - Last updated in NVD database

Technical Details for CVE-2026-105213

Vulnerability Analysis

The vulnerability is an authentication bypass classified under [CWE-287: Improper Authentication]. ZITADEL's Login V2 authentication path evaluates the state of the user record but omits an equivalent check on the owning organization. When an administrator deactivates an organization, the user accounts inside it are expected to lose access immediately. Because the Login V2 code path does not propagate the organization's inactive state into its authorization decision, holders of valid credentials, active sessions, or refresh tokens continue to authenticate successfully. Attackers can also mint new sessions and refresh existing OAuth tokens, extending access well beyond the point of intended revocation.

Root Cause

The root cause is a missing state check in the Login V2 authentication logic. The flow treats user-level status as the only gate on sign-in and token issuance, ignoring the organization-level inactive state. This is a business logic flaw in the authorization pipeline rather than a cryptographic or memory safety defect.

Attack Vector

Exploitation requires no user interaction and no prior privileges beyond possession of valid authentication material tied to a deactivated organization. An attacker with stolen credentials, a surviving browser session, or an unexpired refresh token can submit normal Login V2 requests over the network. The server processes the request, issues or refreshes tokens, and grants access to downstream applications protected by ZITADEL. See the GitHub Security Advisory GHSA-558c-v5wc-9w4q and the VulnCheck Advisory on Zitadel Authentication Bypass for additional detail. No proof-of-concept code is published.

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-105213

Indicators of Compromise

  • Successful authentication events or token issuance for users whose parent organization is marked inactive in ZITADEL.
  • Refresh token grants or new session creations referencing organization IDs that have been deactivated.
  • Access logs from downstream applications showing activity from accounts that should have been offboarded through organization deactivation.

Detection Strategies

  • Correlate ZITADEL audit logs for org.deactivated events with subsequent user.session.created, user.token.issued, or oidc.refresh_token.exchanged events scoped to the same organization.
  • Query identity logs for authentication activity against the Login V2 endpoint grouped by organization state, flagging any success events for inactive tenants.
  • Review OIDC token endpoint traffic for refresh grants whose subject belongs to an organization in the inactive state.

Monitoring Recommendations

  • Forward ZITADEL audit and OIDC access logs to a centralized analytics platform and alert on authentication outcomes that reference deactivated organizations.
  • Baseline the volume of Login V2 and token refresh requests per organization so that activity against suspended tenants is immediately visible.
  • Monitor for unexpected session persistence after organization-wide offboarding workflows complete.

How to Mitigate CVE-2026-105213

Immediate Actions Required

  • Upgrade all ZITADEL 4.x deployments to version 4.17.1 or later.
  • Revoke active sessions and refresh tokens for every user that belongs to a deactivated organization.
  • Audit organization lifecycle events over the retention window to identify authentications that occurred after a deactivation.
  • Rotate credentials for any accounts in previously deactivated organizations that show post-deactivation activity.

Patch Information

ZITADEL addressed the issue in release 4.17.1. The fix adds organization inactive-state verification to the Login V2 authentication path so that session creation, token issuance, and refresh operations fail when the owning organization is deactivated. Refer to the GitHub Security Advisory GHSA-558c-v5wc-9w4q for the authoritative patch notes.

Workarounds

  • Where immediate patching is not possible, deactivate individual users in addition to deactivating the organization, since user-level status is enforced.
  • Explicitly terminate active sessions and revoke outstanding refresh tokens for all members of the organization at the time of deactivation.
  • Restrict network access to the ZITADEL Login V2 endpoint from untrusted locations until the upgrade is applied.
bash
# Configuration example
# Upgrade ZITADEL to the patched release
helm repo update
helm upgrade zitadel zitadel/zitadel --version 4.17.1

# Verify the running version after rollout
kubectl exec -it deploy/zitadel -- zitadel --version

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.