FlawAtlas
Search the atlas
CVE-2026-27946 High

ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API in github.com/zitadel/zitadel

ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API in github.com/zitadel/zitadel. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: github.com/zitadel/zitadel from v2.43.0 before v3.4.7, from v4.0.0 before v4.11.1.

Exploit probability 0.2%
Published March 10, 2026
Required by Not available
Last source change March 23, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

946 explicit affected versions

Go github.com/zitadel/zitadel
Go github.com/zitadel/zitadel

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2026:21483-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities GHSA-282g-fhmx-xf54

### Summary 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. ### Impact Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone. Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user. This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies. Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked. ### Affected Versions Systems running one of the following versions are affected: - **4.x**: `4.0.0` through `4.11.0` (including RC versions) - **3.x**: `3.0.0` through `3.4.6` (including RC versions) - **2.x**: `2.43.0` through `2.71.19` ### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself. 4.x: Upgrade to >=[4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1) 3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7) 2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7) ### Workarounds The recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user. ### Questions If you have any questions or comments about this advisory, please email us at [[email protected]](mailto:[email protected]) ### Credits This vulnerability was identified by [MhdAsfan](https://github.com/MhdAsfan) during a security audit of a system utilizing Zitadel.

View original source
Open Source Vulnerabilities GO-2026-4572

ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API in github.com/zitadel/zitadel. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: github.com/zitadel/zitadel from v2.43.0 before v3.4.7, from v4.0.0 before v4.11.1.

View original source
Open Source Vulnerabilities CVE-2026-27946

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.

View original source

05 / REFERENCES

Further evidence