ZITADEL CVE-2026-109371

Exploitation requires the target to be running ZITADEL's hosted Login V1 UI, where the change-username handler operates on the account bound to a login flow before any authentication factor is verified; the attacker must also know the victim's login name and the victim must be an active human user (service accounts aside). Because PR:N/UI:N applies, no credentials or victim interaction are needed, but the flaw is bounded to Login V1 deployments - instances using a newer login flow or already upgraded to 4.18.0+ are not exposed, which materially limits the exploitable population below the raw network-reachable CVSS implication.

This is a genuine high-priority issue, not a CVSS-inflation case. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network-reachable, low-complexity, fully unauthenticated exploitation with no user interaction, which aligns consistently with the CWE-306 (Missing Authentication) classification and the description's claim that the change-username handler acts before any factor is verified. The impact profile is integrity-dominant (VI:H - attacker renames arbitrary human users including administrators) with a secondary availability effect (VA:L - victims, notably admins, are locked out); confidentiality is untouched (VC:N), so this is an account-takeover-adjacent integrity/DoS flaw rather than a data-disclosure flaw. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation or mass-automation yet; the signals do not conflict, they are simply incomplete. The practical caveat is that exploitation targets ZITADEL's hosted Login V1 UI specifically, so real-world risk concentrates on deployments still running that login flow rather than every ZITADEL instance - defenders should confirm whether Login V1 is enabled before treating this as universally exploitable.

An unauthenticated attacker browses to a victim organization's hosted ZITADEL Login V1 UI, submits a known administrator's login name to bind that account to a login flow, and then - without completing any password or MFA factor - posts a new username to the change-username handler. The administrator's username is silently rewritten, locking the legitimate admin out of the console. No public exploit code was identified at time of analysis, but the attack requires only standard HTTP requests and no special tooling.