CVE-2026-32131: ZITADEL Information Disclosure Flaw

CVE-2026-32131 Overview

A significant authorization bypass vulnerability has been identified in ZITADEL, an open source identity management platform. The flaw exists in ZITADEL's Management API, which allowed authenticated users holding valid low-privilege tokens (such as project.read, project.grant.read, or project.app.read) to retrieve management-plane information belonging to other organizations. This cross-tenant data access was possible by specifying a different tenant's project_id, grant_id, or app_id in API requests.

Critical Impact

Authenticated attackers with minimal privileges can access sensitive management data from other organizations, potentially exposing confidential tenant configurations, project details, and application information across the multi-tenant ZITADEL platform.

Affected Products

• ZITADEL versions prior to 3.4.8
• ZITADEL versions prior to 4.12.2

Discovery Timeline

• 2026-03-11 - CVE-2026-32131 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32131

Vulnerability Analysis

This vulnerability is classified as CWE-639: Authorization Bypass Through User-Controlled Key, a common authorization flaw where the application fails to properly validate that a user is authorized to access resources identified by user-supplied parameters.

In the context of ZITADEL's Management API, the authorization logic does not adequately verify that the requesting user's organization matches the organization associated with the requested resource. When a user submits an API request containing a project_id, grant_id, or app_id, the system checks whether the user holds a valid token with the appropriate read permissions but fails to verify that the requested resource belongs to the user's own tenant.

This Insecure Direct Object Reference (IDOR) pattern allows low-privilege users to enumerate and access sensitive management-plane information from other organizations within the same ZITADEL deployment. The confidentiality impact is significant as attackers can potentially harvest configuration details, project metadata, and application settings from all tenants in the system.

Root Cause

The root cause of this vulnerability lies in insufficient authorization checks within the Management API endpoints. While the API correctly validates that incoming requests contain valid authentication tokens with appropriate scope permissions (e.g., project.read), it fails to implement proper tenant isolation controls. The authorization logic does not verify that the resource identifier provided in the request (such as project_id) belongs to the same organization as the authenticated user. This missing boundary check creates a horizontal privilege escalation scenario where any authenticated user with basic read permissions can access resources across all organizations.

Attack Vector

The attack can be executed remotely over the network by any authenticated user with low-privilege tokens. The attacker needs to:

1. Obtain valid authentication credentials with minimal permissions (e.g., project.read scope)
2. Identify or enumerate valid resource identifiers (project_id, grant_id, or app_id) from other organizations
3. Submit API requests to the Management API with the target organization's resource identifiers
4. Extract sensitive management-plane information from the API responses

The exploitation requires no user interaction and can be automated to systematically harvest data from all accessible tenants. The attack is limited to information disclosure and does not allow modification of resources, though the exposed data could enable further attacks against target organizations.

Detection Methods for CVE-2026-32131

Indicators of Compromise

• API access logs showing requests where the organization ID in the authentication token does not match the organization owning the requested resource
• Unusual patterns of Management API requests querying multiple different project_id, grant_id, or app_id values in quick succession
• Single user accounts making requests for resources across many different organizations
• Increased API error rates or anomalous response patterns on Management API endpoints

Detection Strategies

• Implement audit logging that correlates the authenticated user's organization with the organization of requested resources
• Monitor for enumeration patterns in API requests targeting Management API endpoints
• Deploy anomaly detection rules to flag users accessing resources outside their expected organizational scope
• Review API gateway logs for unusual cross-tenant access patterns

Monitoring Recommendations

• Enable detailed access logging on all Management API endpoints with organization context
• Set up alerts for failed authorization checks that may indicate exploitation attempts
• Monitor for reconnaissance activity such as sequential resource ID enumeration
• Track API usage metrics per organization to identify anomalous data access patterns

How to Mitigate CVE-2026-32131

Immediate Actions Required

• Upgrade ZITADEL to version 3.4.8 or later (for 3.x branch) immediately
• Upgrade ZITADEL to version 4.12.2 or later (for 4.x branch) immediately
• Review audit logs for any suspicious cross-tenant API access prior to patching
• Consider rotating sensitive credentials or tokens that may have been exposed
• Notify affected tenants if evidence of unauthorized data access is discovered

Patch Information

ZITADEL has released security patches addressing this authorization bypass vulnerability. Users should upgrade to the following fixed versions:

• Version 3.4.8: GitHub Release v3.4.8
• Version 4.12.2: GitHub Release v4.12.2

For complete details on the vulnerability and remediation guidance, refer to the GitHub Security Advisory GHSA-wr6r-59xg-4pj2.

Workarounds

• Implement network-level restrictions to limit Management API access to trusted IP ranges
• Deploy a web application firewall (WAF) with rules to detect and block cross-tenant resource access patterns
• Implement additional API gateway validation to verify organization context before forwarding requests
• Temporarily restrict Management API access to only essential administrative users until patching is complete
• Consider implementing rate limiting on Management API endpoints to slow potential enumeration attacks