CVE-2026-54693 allows unauthorized users to request email and phone verification codes for arbitrary addresses, fundamentally corrupting ZITADEL's identity proof-of-ownership model. The CVSS 8.2 score dramatically understates the risk because this isn't just unauthorized access — it poisons the trust foundation every downstream security control depends on. Email and phone verification in ZITADEL aren't convenience features; they're the authoritative mechanism for MFA enrollment, password resets, and account recovery. When attackers can claim ownership of addresses they don't control, they can hijack any account recovery flow that relies on those verification channels.
The vulnerability exists in 'internal/command' paths — code written under the implicit assumption that authorization happens upstream. This is a design gap, not a regression: the permission checks were almost certainly never implemented, not removed. The 'internal' directory designation created a psychological exemption from security scrutiny that developers self-enforced. The simultaneous fix across versions 3.4.11 and 4.15.1 (while v2.x was abandoned entirely) confirms a single root cause that propagated across the entire version history.
For remediation: patch immediately to 3.4.11, 4.15.1, or later. For deployments that cannot upgrade, compensating controls are severely limited. Network isolation helps reduce exposure but conflicts with ZITADEL's core value as a centralized identity provider. Rate limiting on verification code requests throttles abuse but doesn't prevent fraudulent claim submission. Log monitoring for verification codes requested but never used — or for codes requested for addresses that don't match the requesting user's profile — could surface exploitation, but requires active monitoring.
The critical question for incident response: any account that completed email or SMS verification during affected versions (2.x, 3.x prior to 3.4.11, 4.x prior to 4.15.1) should be treated as potentially compromised through social engineering, not just technical exploitation. The trust model those verifications established is architecturally unsound. Consider forcing re-verification of all user email and phone claims if your deployment timeline overlaps with affected versions and you have no other evidence of trust.