8.2

CVSS Score

4.0

-

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-27946

CVE-2026-27946: ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API

ZITADEL is an open source identity management platform. Prior to versions 4.11.1 and 3.4.7, a vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process. The patch in versions 4.11.1 and 3.4.7 resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address and/or phone number itself. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-27946

CVE-2026-27946:

8.2

CVSS Score

4.0

-

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, < 4.11.0	4.11.1
github.com/zitadel/zitadel	go	>= 2.43.0, < 3.4.7	3.4.7
github.com/zitadel/zitadel	go	< 1.80.0-v2.20.0.20260225053417-0261536243e5	1.80.0-v2.20.0.20260225053417-0261536243e5

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The analysis of the provided patch reveals a critical authorization flaw in the ZITADEL platform. The vulnerability, as described, allowed users to bypass email and phone verification processes by directly calling the UpdateHumanUser API on their own user profile and setting the respective fields to a verified state. The root cause was an insufficient permission check within the (*Commands).ChangeUserHuman function located in internal/command/user_v2_human.go.

The provided commit 0261536243e500dccfd8c7f547d592c822478327 clearly shows the fix. Before the patch, the decision to enforce a stricter permission check was based solely on whether user metadata was being changed. The act of setting an email or phone number to 'verified' was not considered a metadata change, allowing the operation to proceed under the user's own, lower-privileged context. The patch rectifies this by introducing a new variable, requireWritePermission, which becomes true if a user attempts to set the Verified flag on their email or phone. This triggers the stricter permission check, checkPermissionUpdateUser, which correctly denies the operation in a self-management context. The added integration and unit tests in the same commit confirm this behavior by asserting that an error is returned when a user tries to self-verify their contact information.

Therefore, the function (*Commands).ChangeUserHuman is the specific location of the vulnerability. During exploitation, this function would be present in runtime profiles and stack traces as it is the core component responsible for processing the malicious request and failing to enforce proper authorization.

Vulnerable functions

(*Commands).ChangeUserHuman

internal/command/user_v2_human.go

The vulnerability lies in the `ChangeUserHuman` function, which processes updates to user profiles. Previously, the permission check, `checkPermissionUpdateUser`, did not account for a user attempting to self-verify their email or phone number. The `!metadataChanged` condition was insufficient because changing the verification status was not considered a metadata change that required elevated permissions. An attacker could exploit this by calling the `UpdateHumanUser` API on their own account and setting the `is_verified` flag for their email or phone to `true`. The patch addresses this by introducing `requireWritePermission`, which explicitly checks if the `Verified` flag is being set for the user's email or phone. If it is, the function now requires write permissions, which a user does not have for self-management, thus preventing the unauthorized verification.

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.