5.3

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-33132

CVE-2026-33132: Zitadel is missing enforcement of organization scopes

ZITADEL is an open source identity management platform. Versions prior to 3.4.9 and 4.0.0 through 4.12.2 allowed users to bypass organization enforcement during authentication. Zitadel allows applications to enforce an organzation context during authentication using scopes (urn:zitadel:iam:org:id:{id} and urn:zitadel:iam:org:domain:primary:{domainname}). If enforced, a user needs to 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. This allowed users to bypass the restriction and sign in with users from other organizations. Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass. This issue has been patched in versions 3.4.9 and 4.12.3.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-33132

CVE-2026-33132:

5.3

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/zitadel/zitadel	go	>= 4.0.0-rc.1, <= 4.12.2	4.12.3
github.com/zitadel/zitadel	go	>= 3.0.0-rc.1, < 3.4.9	3.4.9
github.com/zitadel/zitadel	go	< 1.80.0-v2.20.0.20260317120401-d90285929ca0	1.80.0-v2.20.0.20260317120401-d90285929ca0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, GHSA-g2pf-ww5m-2r9m, stems from a failure to enforce organization-specific scopes (urn:zitadel:iam:org:id:{id} and urn:zitadel:iam:org:domain:primary:{domainname}) across various authentication flows in Zitadel. This allowed a user belonging to one organization to authenticate into an application that should have been restricted to a different organization.

The analysis of the patch commit d90285929ca019fa817f31551fd0883429dda2a8 reveals that the issue was addressed by adding checks at multiple layers of the authentication and authorization process.

Auth Request Creation: The function createAuthRequestScopeAndAudience in internal/api/oidc/auth_request.go was modified to validate and extract the organization ID from the scopes. Previously, it ignored these scopes, creating a loophole where the organization context was lost at the beginning of the flow.
Session and Device Flow Enforcement: The core logic in the internal/command package was updated. Functions like LinkSessionToAuthRequest, ApproveDeviceAuth, and ApproveDeviceAuthWithSession now explicitly check if the user's organization matches the organization ID stored in the authentication or device authorization request. Before the patch, these checks were missing, allowing a session from any organization to be used.
Frontend UI: In the Login V2 application, the TypeScript functions loadSessions and findValidSession were updated to filter a user's sessions based on the required organization. This prevents a user from selecting or being automatically logged in with a session associated with an incorrect organization.

In summary, the exploitation of this vulnerability would involve functions responsible for creating authentication requests, linking user sessions, and handling device authorization approvals. The identified vulnerable functions are the points where the organization scope was not being enforced, allowing the bypass.

Vulnerable functions

github.com/zitadel/zitadel/internal/api/oidc.(*OPStorage).createAuthRequestScopeAndAudience

internal/api/oidc/auth_request.go

This function was responsible for processing scopes during authentication request creation. Before the patch, it did not validate or extract the organization from the scopes. This allowed the creation of authentication requests that were not correctly bound to an organization, even when an organization scope was provided. The patch adds a call to `assertOrgScope` to enforce this.

github.com/zitadel/zitadel/internal/command.(*Commands).LinkSessionToAuthRequest

internal/command/auth_request.go

This function links an existing user session to an authentication request. The vulnerability existed because this function did not check if the organization of the user's session matched the organization required by the authentication request. This allowed a user from one organization to hijack an authentication flow for another organization.

github.com/zitadel/zitadel/internal/api/oidc.(*OPStorage).StoreDeviceAuthorization

internal/api/oidc/device_auth.go

When initiating a device authorization flow, this function failed to extract and store the organization ID from the provided scopes. This meant that the subsequent approval step had no organization context to validate against.

github.com/zitadel/zitadel/internal/command.(*Commands).ApproveDeviceAuth

internal/command/device_auth.go

When a user approves a device authorization, this function is called. It was vulnerable because it did not check if the approving user's organization matched the organization specified in the initial device authorization request (as this was not stored). This allowed a user from any organization to approve a device flow.

github.com/zitadel/zitadel/internal/command.(*Commands).ApproveDeviceAuthWithSession

internal/command/device_auth.go

Similar to `ApproveDeviceAuth`, this function approves a device authorization using an existing session. It was vulnerable because it did not validate that the organization of the user's session matched the organization required by the device authorization flow.

findValidSession

apps/login/src/lib/session.ts

In the Login V2 UI, this function is used to find a valid session for a user. It was vulnerable as it did not filter sessions based on the organization context provided in the authentication request, potentially leading to the use of a session from an incorrect organization.

loadSessions

apps/login/src/app/(login)/accounts/page.tsx

This function, used in the account selection page of the Login V2 UI, was vulnerable because it loaded all of a user's sessions without filtering them by the required organization. This could present the user with sessions that are not valid for the current authentication flow.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.