Summary
ZITADEL Login V2 may authenticate users from organizations that have been deactivated because it verifies the individual user's status without checking the organization's inactive state. Users with valid credentials, an existing session, or a refresh token may therefore continue signing in, creating sessions, or obtaining and refreshing tokens.
Affected context
The issue occurs in ZITADEL 4.x deployments using Login V2 authentication when an organization has been deactivated but user-level authentication checks remain valid. It is relevant where users retain valid credentials, active sessions, or refresh tokens after the organization-level state changes.
Exploit preconditions
- Attack surface: Login V2 authentication and token-refresh flows
- Required access: Valid credentials, an existing authenticated session, or a valid refresh token associated with a user in a deactivated organization
- Trigger point: User sign-in, session creation, or access and refresh token issuance
- Why exploitation is possible: The authentication flow checks the individual user's state without consistently enforcing the organization's inactive status
Why this happens
The underlying bug is an incomplete authentication-state validation sequence. Login V2 treats a user-level status check as sufficient while failing to incorporate the parent organization's deactivated state into authorization decisions. This maps to CWE-287: Improper Authentication, because the system may establish or maintain authenticated access without validating all security-relevant identity and account conditions.
Potential impact
- Users from deactivated organizations may continue to authenticate
- The system may create new sessions for accounts that should be inactive
- Access and refresh tokens may be issued or renewed after organization deactivation
- Applications and resources associated with the organization could remain accessible
- Administrative deactivation controls may be weakened
General mitigation guidance
Mitigation generally focuses on making organization-level state a mandatory part of every authentication and token decision.
Common defensive patterns include:
- Enforcing organization status checks during login, session creation, and token refresh
- Revalidating organization and user state when existing sessions or refresh tokens are used
- Rejecting tokens whose issuing context is no longer active
- Applying fail-closed behavior when organization state cannot be retrieved or evaluated
- Centralizing authentication and authorization policy checks to prevent inconsistent enforcement
- Limiting session and token privileges according to current organizational status
- Testing account deactivation and reactivation flows across all authentication paths
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and architectural analysis of authentication flows for missing parent-account or tenant-state checks
- Code review signals where user validation occurs without organization or account-container validation
- Integration tests covering deactivated organizations, existing sessions, and refresh-token use
- Monitoring for successful logins, new sessions, or token refreshes after organization deactivation
- Policy enforcement requiring centralized authorization checks for login and token endpoints
- Automated security review tools that identify inconsistent authentication-state validation
