CVE-2026-32131: 
NixOS vulnerability analysis and mitigation

CVE-2026-32131 is a cross-tenant information disclosure vulnerability in ZITADEL's Management API, classified as High severity. It allows authenticated users holding low-privilege tokens (e.g., project.read, project.grant.read, or project.app.read) to retrieve management-plane information belonging to other organizations by supplying a different tenant's project_id, grant_id, or app_id. Affected versions include ZITADEL 3.x prior to 3.4.8, 4.0.0 through 4.12.1, and 2.x through 2.71.19. The vulnerability was published on March 11, 2026, with patches released the same day. It carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory).

The root cause is a missing assertion that verifies a retrieved resource belongs to the requesting user's organization, classified under CWE-639 (Authorization Bypass Through User-Controlled Key), CWE-862 (Missing Authorization), and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) (GitHub Advisory). An attacker with any valid low-privilege token can craft API requests to the following affected endpoints — GetProjectByID, GetGrantedProjectByID, GetProjectGrantByID, GetAppByID, ListApps, ListHumanAuthFactors, and ListHumanPasswordless — substituting a target tenant's resource ID to retrieve their data. The attack requires network access to the Management API, a valid low-privilege token for any organization, and knowledge or enumeration of the target tenant's resource IDs (project_id, grant_id, app_id, or user_id). The fix enforces that retrieved resources must belong to the organization associated with the requesting token (GitHub Advisory).

Successful exploitation enables cross-organization data exposure within a shared ZITADEL instance, allowing an attacker to read sensitive OIDC configuration data such as clientId, redirectUris, and allowedOrigins belonging to other tenants. This confidentiality breach could facilitate further attacks — for example, using disclosed redirect URIs or client IDs to craft phishing or OAuth abuse campaigns against victim organizations. There is no integrity or availability impact; the vulnerability is purely a confidentiality issue with a changed scope, meaning resources outside the attacker's security boundary are affected (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of active in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.027%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Obtain a low-privilege token: Register or authenticate to any organization on the target ZITADEL instance and obtain a valid token with at least one of the following permissions: project.read, project.grant.read, project.app.read, or user.read.
2. Enumerate target resource IDs: Attempt to discover or guess valid project_id, grant_id, app_id, or user_id values belonging to other organizations. These may be UUIDs that could be brute-forced or inferred from public-facing application configurations.
3. Craft a cross-tenant API request: Using the low-privilege token, send an authenticated request to a vulnerable Management API endpoint (e.g., GetProjectByID or GetAppByID) substituting the target tenant's resource ID in place of one belonging to the attacker's own organization.
4. Retrieve sensitive data: The API returns management-plane information for the target tenant's resource — including OIDC configuration details such as clientId, redirectUris, and allowedOrigins — without validating organizational ownership.
5. Leverage disclosed information: Use the retrieved OIDC configuration data to facilitate further attacks such as OAuth token hijacking, phishing, or unauthorized application impersonation against the victim organization (GitHub Advisory).

• Network: Unusual Management API requests (e.g., GetProjectByID, GetAppByID, ListApps) where the resource IDs in the request do not correspond to any project or application registered under the authenticated user's organization.
• Logs: ZITADEL audit logs showing repeated Management API calls from a single low-privilege token accessing resource IDs across multiple organizations; sequential or pattern-based enumeration of project_id, grant_id, or app_id values.
• Behavioral: A single authenticated user or service account making high-volume read requests to Management API endpoints for resources they do not own; access patterns inconsistent with the user's assigned organization.

ZITADEL has released patched versions addressing this vulnerability: upgrade to 3.4.8 or later for the 3.x branch, 4.12.2 or later for the 4.x branch, or 3.4.8 or later for 2.x users (GitHub v3.4.8 Release, GitHub v4.12.2 Release). As a temporary workaround for deployments that cannot upgrade immediately and no longer rely on the Management V1 API, access to the API can be blocked via a reverse proxy or WAF rule. Additionally, administrators should review low-privilege token assignments, apply the principle of least privilege, and audit Management API logs for suspicious cross-organization access patterns prior to patching (GitHub Advisory).

The vulnerability was reported by security researcher odgrso and remediated by ZITADEL maintainers livio-a and muhlemmer, with the advisory published on March 11, 2026 (GitHub Advisory). Brief community mentions appeared on Mastodon and Bluesky shortly after disclosure, though no significant in-depth analysis or media coverage has been identified. The coordinated same-day patch release was noted positively by community members reacting to the v4.12.2 release on GitHub.