ZITADEL Authorization Bypass: Self-Verification of Email and Phone

ZITADEL is an open-source identity management system that provides self-service capabilities for users to manage their profiles, including email addresses and phone numbers. Ideally, modifying sensitive attributes such as the verification status of contact information requires administrative privileges or a completed verification flow (e.g., clicking a link sent to the email). CVE-2026-27946 represents a failure in the authorization logic governing these updates.

The vulnerability exists specifically within the UpdateHumanUser command in the V2 API. When processing user updates, the system failed to correctly categorize the Verified flag as a protected attribute. Consequently, the authorization check treated a request setting Verified: true as a standard self-service profile update rather than a privileged administrative action. This allows any authenticated user to unilaterally declare their contact methods as verified.

The root cause of this vulnerability lies in the permission evaluation logic within the ChangeUserHuman command handler, specifically in internal/command/user_v2_human.go. The handler uses a helper function, checkPermissionUpdateUser, to determine if the requesting user has the necessary rights to perform the update. This function accepts a boolean argument—often named allowSelf—which dictates whether the operation can be performed by the user on their own account without the user.write permission.

In the vulnerable implementation, the code calculated allowSelf based primarily on whether metadata was being changed. The logic assumed that if metadataChanged was false, the user was modifying standard profile fields (like name or display name) which are permissible for self-update. However, the logic failed to account for the Email.Verified and Phone.Verified fields. These fields were not flagged as requiring write permission, so the system permitted users to inject Verified: true into the update payload. The backend then persisted this state to the database, effectively bypassing the verification controller entirely.

The patch introduces a strict check to determine if the update payload attempts to modify the verification status of an email or phone number. If such a modification is detected, the system forces an administrative permission check.

Vulnerable Logic:

// The system checks if metadata is changing. If not, it allows self-update.
// This overlooks the 'Verified' field in the 'human' struct.
if err := c.checkPermissionUpdateUser(ctx, ..., !metadataChanged); err != nil {
    return nil, err
}

Patched Logic (Commit 0261536243):

// The fix explicitly defines conditions that require write (admin) permission.
// This now includes attempting to set the verified flag on email or phone.
requireWritePermission := metadataChanged || 
    (human.Email != nil && human.Email.Verified) || 
    (human.Phone != nil && human.Phone.Verified)
 
// The 'allowSelf' argument is now '!requireWritePermission'.
// If the user tries to verify themselves, requireWritePermission is true,
// causing allowSelf to be false, triggering a permission error for standard users.
if err := c.checkPermissionUpdateUser(ctx, ..., !requireWritePermission); err != nil {
    return nil, err
}

By expanding the definition of requireWritePermission, the developers ensured that the verification status can only be modified by an actor holding the user.write permission or through the dedicated verification flows that bypass this specific handler.

Exploitation of this vulnerability is trivial for an authenticated attacker and requires no specialized tools beyond a standard HTTP client.

Prerequisites:

1. A valid user account on a vulnerable ZITADEL instance.
2. Access to the ZITADEL V2 API endpoints.

Attack Steps:

1. The attacker authenticates to obtain a session token.
2. The attacker constructs a JSON payload for the UpdateUser endpoint targeting their own User ID.
3. The payload includes the human object with an email or phone number and explicitly sets the verification flag.

Sample Payload:

{
  "userId": "<CURRENT_USER_ID>",
  "human": {
    "email": {
      "address": "attacker@malicious.com",
      "isVerified": true
    }
  }
}

Outcome: Upon sending this request, the server returns a 200 OK response. The user profile is immediately updated in the database with email_verified = true. The attacker can now proceed to perform actions that require a verified email, such as resetting passwords without email confirmation (if configured) or enrolling in MFA factors that rely on verified contact channels.

The ability to self-verify contact information undermines the trust model of the identity provider. While the CVSS score is High (8.2), the practical impact depends on how the organization relies on the Verified status.

Security Implications:

• MFA Bypass / Enrollment: Attackers may be able to register new MFA devices or recover accounts using phone numbers they do not actually control, provided they can verify them via this exploit.
• Trust Integrity: Downstream applications relying on the email_verified claim in OIDC tokens will inherently trust the attacker's unverified email. This is critical for applications that auto-provision accounts based on email domain trust.
• Notification Spoofing: An attacker could register a victim's email address to their own account and mark it as verified, potentially intercepting sensitive notifications or causing confusion in user directories.

Metric Breakdown (CVSS v4.0):

• Attack Vector: Network (exploitable remotely).
• Privileges Required: Low/None (depending on self-registration). Any standard user can exploit this.
• Integrity Impact: High (Direct modification of trust anchors).