Zitadel EUVD-2026-50418

Requires an authenticated Zitadel account and use of the self-management API path that returns the verification code to the caller (the returnCode/return-code option on the email or phone change or send-code flow). The specific condition is self-managing your OWN email or phone while requesting the code be returned in-band instead of delivered via email/SMS - that returned code is what enables 'verifying' an address you do not control. Limiting factors: the attacker must already hold valid credentials (this is not fully unauthenticated despite the vendor's PR:N rating), and operations against ANOTHER user's email/phone remain correctly permission-checked, confining abuse to the attacker's own account. Affected only on Zitadel 2.43.0-2.71.19, 3.0.0-3.4.10, and 4.0.0-4.15.0.

The vendor scores this 8.2 (High) on CVSS 4.0 (AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SI:H), reflecting network reach, low complexity, and high integrity impact on both the vulnerable system and email-trust-dependent subsequent systems. However, the description clearly frames the flaw as self-management by an authenticated user, which conflicts with the vendor's PR:N - an attacker must already hold a valid Zitadel account, so a privilege requirement of at least PR:L is more defensible; verify the PR rating against your deployment. There is no CISA KEV listing and no public proof-of-concept in the provided data, so this is not confirmed actively exploited and no EPSS-driven mass-exploitation signal is present. Real-world priority is moderate-to-high for identity-critical deployments: the impact (forging verified contact ownership to bypass email-based trust, account recovery, or policy gates) is serious, but exploitation is gated by needing an authenticated account and by the fact that changing another user's data remains correctly permission-checked. EPSS and SSVC/automatable data were not supplied.

An authenticated Zitadel user calls the self-management API to change their email (or phone) to an address they do not own, requesting the verification code be returned in the API response (returnCode) rather than emailed to the real owner. The API returns the plaintext code, the attacker submits it to complete 'verification,' and their account now shows a verified email they never controlled - satisfying email-based security policies or asserting ownership of that identifier. No public PoC is available, but the attack is low-complexity for anyone with a valid account.