CVE-2026-33132: Zitadel Auth Bypass Vulnerability

CVE-2026-33132 Overview

ZITADEL, an open source identity management platform, contains an authorization bypass vulnerability that allows users to circumvent organization enforcement during authentication. The vulnerability affects versions prior to 3.4.9 and versions 4.0.0 through 4.12.2, enabling attackers to bypass organization-specific access controls and authenticate with users from unauthorized organizations.

ZITADEL allows applications to enforce an organization context during authentication using scopes (urn:zitadel:iam:org:id:{id} and urn:zitadel:iam:org:domain:primary:{domainname}). When enforced, users must be part of the required organization to sign in. While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints.

Critical Impact

Users can bypass organization restrictions and sign in with users from other organizations, potentially compromising multi-tenant isolation and enabling unauthorized cross-organization access.

Affected Products

• ZITADEL versions prior to 3.4.9
• ZITADEL versions 4.0.0 through 4.12.2
• ZITADEL Login V2 and OIDC API V2 endpoints

Discovery Timeline

• 2026-03-20 - CVE-2026-33132 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-33132

Vulnerability Analysis

This authorization bypass vulnerability (CWE-863: Incorrect Authorization) stems from inconsistent enforcement of organization scope validation across different authentication endpoints. The ZITADEL identity management platform implements organization-level access controls through scope parameters in OAuth2/OIDC flows, but these controls were only enforced in the legacy login V1 implementation.

The vulnerability allows an attacker with valid credentials from one organization to authenticate against applications configured to enforce a different organization's context. This breaks the fundamental multi-tenant isolation model that ZITADEL provides, potentially enabling unauthorized access to organization-specific resources and data.

Applications that rely solely on organization enforcement during authentication are affected by this bypass. However, applications that implement additional authorization checks through roles and permissions are not impacted, as those controls are evaluated post-authentication.

Root Cause

The root cause is missing authorization validation in the newer authentication endpoints. While the login V1 OAuth2/OIDC authorization handler properly validated organization scopes, the following components lacked equivalent controls:

1. Device Authorization Requests - The device flow did not validate organization membership
2. Login V2 Endpoints - The modernized login implementation omitted organization scope enforcement
3. OIDC API V2 Endpoints - The updated OIDC API lacked organization context validation

The session listing and validation functions did not filter sessions by organization context, allowing sessions from any organization to satisfy authentication requirements.

Attack Vector

An attacker exploits this vulnerability by initiating authentication through one of the affected endpoints (device authorization, login V2, or OIDC API V2) while specifying an organization scope that differs from their actual organization membership. The attack is network-accessible and requires no prior authentication to the target organization, though the attacker must possess valid credentials for some organization within the ZITADEL instance.

The following patch demonstrates the fix applied to enforce organization filtering during session validation:

     } else if (authRequest.prompt.includes(Prompt.NONE)) {
       const securitySettings = await getSecuritySettings({ serviceConfig });

-      const selectedSession = await findValidSession({ serviceConfig, sessions, authRequest });
+      const selectedSession = await findValidSession({ serviceConfig, sessions, authRequest, organization });

       const noSessionResponse = NextResponse.json({ error: "No active session found" }, { status: 400 });
       setCSPHeaders(noSessionResponse, serviceConfig, securitySettings);

Source: GitHub Commit d90285929ca019fa817f31551fd0883429dda2a8

The session loading function was also updated to filter sessions by organization context:

   return { title: t("title") };
 }
 
-async function loadSessions({ serviceConfig }: { serviceConfig: ServiceConfig }) {
+async function loadSessions({
+  serviceConfig,
+  organization,
+}: {
+  serviceConfig: ServiceConfig;
+  organization?: string;
+}) {
   const cookieIds = await getAllSessionCookieIds();
 
   if (cookieIds && cookieIds.length) {
-    const response = await listSessions({ serviceConfig, ids: cookieIds.filter((id) => !!id) as string[],
+    const response = await listSessions({
+      serviceConfig,
+      ids: cookieIds.filter((id) => !!id) as string[],
     });
-    return response?.sessions ?? [];
+
+    let sessions = response?.sessions ?? [];
+    if (organization) {
+      sessions = sessions.filter((s) => s.factors?.user?.organizationId === organization);
+    }
+
+    return sessions;
   } else {
     console.info("No session cookie found.");
     return [];

Source: GitHub Commit d90285929ca019fa817f31551fd0883429dda2a8

Detection Methods for CVE-2026-33132

Indicators of Compromise

• Authentication logs showing successful logins where the user's organization ID does not match the requested organization scope
• Device authorization requests followed by successful authentication from users outside the enforced organization
• Unusual cross-organization access patterns in OIDC token issuance logs
• Login V2 or OIDC API V2 endpoint requests with organization scope parameters that don't match the authenticated user's membership

Detection Strategies

• Monitor authentication logs for organization scope mismatches by comparing urn:zitadel:iam:org:id:{id} scopes against the authenticated user's organizationId
• Alert on successful authentications via device authorization flow where organization enforcement is expected but user membership differs
• Implement log correlation between OIDC token requests and user organization membership records
• Review access logs for Login V2 and OIDC API V2 endpoints for anomalous authentication patterns

Monitoring Recommendations

• Enable detailed audit logging for all authentication endpoints including device authorization, Login V2, and OIDC API V2
• Configure alerts for authentication events where the organization scope in the request differs from the user's actual organization
• Implement continuous monitoring of cross-organization authentication attempts
• Review historical authentication logs for evidence of exploitation prior to patching

How to Mitigate CVE-2026-33132

Immediate Actions Required

• Upgrade ZITADEL to version 3.4.9 or 4.12.3 immediately
• Review authentication logs for signs of organization bypass exploitation
• Audit applications relying solely on organization enforcement without additional role-based authorization
• Consider implementing additional authorization checks at the application level as defense-in-depth

Patch Information

Security patches have been released to address this vulnerability:

• Version 3.4.9 - Patches versions prior to 3.4.9 in the 3.x branch. See GitHub Release v3.4.9
• Version 4.12.3 - Patches versions 4.0.0 through 4.12.2 in the 4.x branch. See GitHub Release v4.12.3

The fix adds organization context validation to the loadSessions and findValidSession functions, ensuring sessions are filtered by organization membership before authentication succeeds. See the GitHub Security Advisory GHSA-g2pf-ww5m-2r9m for complete details.

Workarounds

• Implement role-based authorization checks at the application layer rather than relying solely on organization enforcement during authentication
• Restrict access to Login V2 and OIDC API V2 endpoints at the network level if not required
• Disable device authorization flow if not actively used in your deployment
• Add application-level validation to verify user organization membership post-authentication

# Configuration example
# Review and restrict OIDC endpoint access at reverse proxy level
# Example nginx configuration to limit access to specific endpoints

# Restrict device authorization endpoint access
location /oauth/v2/device_authorization {
    # Limit to known client IP ranges or disable if unused
    deny all;
    # Or allow specific networks:
    # allow 10.0.0.0/8;
    # deny all;
}