Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-54693

CVE-2026-54693: ZITADEL Auth Bypass Vulnerability

CVE-2026-54693 is an authentication bypass flaw in ZITADEL identity management platform that allows users to claim unauthorized email addresses or phone numbers. This article covers technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-54693 Overview

CVE-2026-54693 is an improper authorization vulnerability [CWE-863] in ZITADEL, an open source identity and access management platform. The flaw resides in the email and phone self-management API paths implemented in internal/command/user_v2_email.go, internal/command/user_v2_phone.go, and internal/command/user_v2_human.go. Authenticated users can request returned verification codes without holding the required permission. This allows attackers to claim ownership of email addresses or phone numbers they do not control, bypassing email-based or phone-based security policies. The issue affects versions 2.43.0 through 2.71.19, 3.0.0 up to 3.4.11, and 4.0.0 up to 4.15.1.

Critical Impact

Attackers can bypass email and phone verification controls, enabling account takeover paths and identity policy circumvention within ZITADEL-managed tenants.

Affected Products

  • ZITADEL versions 2.43.0 through 2.71.19
  • ZITADEL versions 3.0.0 up to (but not including) 3.4.11
  • ZITADEL versions 4.0.0 up to (but not including) 4.15.1

Discovery Timeline

  • 2026-07-29 - CVE-2026-54693 published to NVD
  • 2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-54693

Vulnerability Analysis

ZITADEL exposes user self-management APIs that let end users update their own email address and phone number. Before the patch, the permission check for these endpoints always granted self-management access, regardless of whether the caller requested a returned verification code (returnCode = true). Requesting the code back in the API response is an administrative capability, because it bypasses the out-of-band delivery channel that normally proves ownership of an email inbox or phone number.

By requesting a returned code, an unprivileged user can update another identity's email or phone contact, receive the verification token in the response, and complete the verification without ever controlling the target contact. This defeats downstream security controls that rely on verified contact ownership, including password reset flows, MFA enrollment, and notification-based policies. The weakness is tracked under CWE-863: Incorrect Authorization.

Root Cause

The root cause is a hardcoded true passed as the allowSelfManagement argument to checkPermissionUpdateUser. The permission gate did not consider whether the request asked for the verification code to be returned inline. The patch derives allowSelfManagement from !returnCode, and treats ReturnCode on email and phone objects as requiring write permission, alongside Verified.

Attack Vector

An authenticated ZITADEL user sends a user update request via the v2 API to modify another user's email or phone attribute with the return-code option enabled. The server accepts the change under self-management permissions and returns a valid verification code, which the attacker then submits to mark the contact as verified.

go
// Patch: internal/command/user_v2_email.go
// fix(api): check permission based on provided data on user updates
	if err != nil {
		return nil, err
	}
-	if err = c.checkPermissionUpdateUser(ctx, cmd.aggregate.ResourceOwner, userID, true); err != nil {
+	allowSelfManagement := !returnCode
+	if err = c.checkPermissionUpdateUser(ctx, cmd.aggregate.ResourceOwner, userID, allowSelfManagement); err != nil {
		return nil, err
	}
	if err = cmd.Change(ctx, domain.EmailAddress(email)); err != nil {

// Patch: internal/command/user_v2_human.go
	if human.Changed() {
		// Changing metadata or setting email, resp. phone to verified is only allowed with user write permissions, but not for self-management.
-		requireWritePermission := metadataChanged || (human.Email != nil && human.Email.Verified) || (human.Phone != nil && human.Phone.Verified)
+		requireWritePermission := metadataChanged ||
+			(human.Email != nil && (human.Email.Verified || human.Email.ReturnCode)) ||
+			(human.Phone != nil && (human.Phone.Verified || human.Phone.ReturnCode))
		if err := c.checkPermissionUpdateUser(ctx, existingHuman.ResourceOwner, existingHuman.AggregateID, !requireWritePermission); err != nil {
			return err
		}

Source: ZITADEL commit 90f3102

Detection Methods for CVE-2026-54693

Indicators of Compromise

  • Unexpected email or phone number changes on user accounts, particularly changes performed by a caller that is not the account owner or an administrator.
  • API requests to the v2 user update endpoints where returnCode is set to true originating from non-privileged accounts.
  • Verification events (email.verified, phone.verified) occurring within seconds of an update request from the same session, without corresponding out-of-band delivery events.
  • Password reset or MFA re-enrollment flows initiated shortly after a contact change.

Detection Strategies

  • Parse ZITADEL audit logs for user.human.email.changed and user.human.phone.changed events and correlate the acting user with the target user; alert on mismatches.
  • Flag any API call that both changes contact data and includes returnCode: true when the caller lacks the user.write permission.
  • Establish a baseline of self-service contact update volume per tenant and alert on statistical deviations.

Monitoring Recommendations

  • Forward ZITADEL audit and admin API logs to a centralized analytics pipeline for longitudinal review.
  • Continuously monitor for privileged operations on identity infrastructure, including changes to verified contact attributes.
  • Correlate identity events with downstream authentication activity to identify contact-change-then-reset attack sequences.

How to Mitigate CVE-2026-54693

Immediate Actions Required

  • Upgrade ZITADEL to version 3.4.11 or 4.15.1 as soon as possible; there is no supported fix for the 2.x branch listed in the advisory.
  • Review audit logs since 2.43.0 was deployed for anomalous email or phone changes and forcibly re-verify contact data for high-value accounts.
  • Rotate credentials and reset MFA for any accounts whose contact information was changed by another identity.
  • Restrict the roles allowed to call the v2 user update APIs while validating that upgrades are complete across all tenants.

Patch Information

The issue is fixed in ZITADEL v3.4.11 and ZITADEL v4.15.1. Details are published in the vendor's GitHub Security Advisory GHSA-jq8w-8q2f-ffm9. The remediation changes the permission logic so that requesting a returned verification code (returnCode = true) requires user write permission, as shown in the commits 90f3102, a1748b2, and ed09b3d.

Workarounds

  • No official workaround is provided by the vendor; upgrading to a patched release is the recommended action.
  • If patching cannot occur immediately, block or gate access to the v2 user update endpoints at the API gateway for non-administrative principals.
  • Disable self-service email and phone change flows temporarily and route contact changes through an administrative approval process.
bash
# Example: verify running ZITADEL version and upgrade via container image
docker inspect --format '{{.Config.Image}}' zitadel

# Pull a patched release
docker pull ghcr.io/zitadel/zitadel:v4.15.1
# or for the 3.x branch
docker pull ghcr.io/zitadel/zitadel:v3.4.11

# Redeploy with the patched image and confirm version
docker exec zitadel /app/zitadel --version

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.