github.com/zitadel/zitadel: Unauthenticated attacker can rename any user (including admins) through the login V1

Summary

ZITADEL’s hosted Login V1 UI allowed an unauthenticated attacker who knows only a victim’s login name to permanently change that account’s username. By starting an ordinary login flow, submitting the victim’s login name to identify the account, and then posting a new username, the attacker could rename any active human user on the instance — including administrators — without ever supplying a password or any second factor.

The change-username request acted on the account bound to the login flow as soon as a login name had been entered, before the flow had reached the change-username step and before any authentication factor had been verified.

Impact

An attacker with only network access to the hosted Login V1 UI and knowledge of a victim’s login name can:

• Rename any active human account on the instance, across every organization, including instance administrators
• Lock the victim out of their account, because the identifier they previously logged in with no longer resolves to them
• Free the victim’s former login name for re-registration, where the organization’s login policy permits self-registration or domain discovery, enabling squatting of the released identifier

This affects deployments that authenticate users through ZITADEL’s hosted Login V1 UI (OIDC/SAML).

On its own this issue does not grant account takeover: no password, session, or token is disclosed, and the attacker cannot authenticate as the victim. The impact is to integrity (unauthorized modification of account identifiers) and availability (lockout of the legitimate owner). Machine and service accounts are not affected, because the login-name step binds only active human users, so a non-human account cannot be selected as the rename target through this flow. The standalone Login V2 application does not expose this change-username flow and is not vulnerable through it.

Scope note: This is an instance-wide, cross-organization flaw on the hosted Login V1 surface: any active human in any organization on the instance can be renamed by an anonymous caller. It does not cross instance boundaries. It shares its root cause with GHSA-72q5-mv5c-vxv4 — a Login V1 flow handler that acted on the account bound by login name before the flow had reached the relevant step or verified a factor, fixed the same way by gating the handler on the flow’s current step. That advisory covered unauthenticated MFA enrollment and phone-number overwrite; this one covers the username change.

Affected Versions

Systems running one of the following versions are affected:

• 4.x: 4.0.0 through 4.17.3 (including RC versions)
• 3.x: 3.0.0 through 3.4.15 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The hosted Login V1 UI now performs a username change only once the login flow has legitimately reached the change-username step, which is presented only after the first factor and any required multi-factor checks have succeeded. A request that has merely identified an account by login name can no longer trigger a rename.

• 4.x: Upgrade to $\ge$ [v4.19.1](https://github.com/zitadel/zitadel/releases/tag/v4.19.1)

⚠️ Please skip the v4.18.0 release and use v4.19.1. The setup step fails in this version (https://github.com/zitadel/zitadel/issues/12780).

The 3.x release line reached end-of-life on 2026-08-31 and will not receive a fix for this vulnerability. Affected 3.x deployments must upgrade to a patched 4.x release.

Workarounds

The recommended solution is to upgrade to a patched version. There is no configuration that fully closes this gap on unpatched versions.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Adam Korczynski (Ada Logics) for reporting the vulnerability.