CVE-2025-64103 is a critical (CVSS 9.8) multi factor authentication bypass in ZITADEL. Sessions with only one verified factor could be treated as fully authenticated, even for users who had set up MFA. ZITADEL 4.6.0, 3.4.3 and 2.71.18 fix it, so upgrade your major line.
What's affected
The GitHub advisory (GHSA-cfjq-28r2-4jv5) lists the affected systems as those using the session API (v2 beta and v2), directly or through the new login UI. The versions are:
- 4.x: 4.0.0 to 4.5.0, release candidates included
- 3.x: 3.0.0 to 3.4.2, release candidates included
- 2.x: 2.53.6 to 2.53.9, 2.54.3 to 2.54.10, and 2.55.0 to 2.71.17
The fixed releases are 4.6.0, 3.4.3 and 2.71.18. The advisory metadata shows no patched release for the 2.53.x and 2.54.x lines, so those users should move to the 2.71.18 line or later.
How to check if you're exposed
Start with the version you run. For containers:
docker ps --format '{{.Names}} {{.Image}}'
For Go projects that pull in ZITADEL modules:
go list -m all | grep -i zitadel
Then work out whether you use the session API or the new login UI. If your applications or a custom login frontend call the session endpoints, you are in scope for this issue. Finally, review your login policy. The advisory explains that the flaw applied when the policy had neither requireMFA nor requireMFAForLocalUsers set, yet individual users had enrolled a second factor. Those are exactly the accounts people assume are protected.
What to do now
- Upgrade to ZITADEL 4.6.0, 3.4.3 or 2.71.18 or later.
- Confirm after the upgrade that a user with a configured second factor is asked for it regardless of the policy flags. The patch requires a configured second factor whatever the policy says.
- If you run a 2.53.x or 2.54.x release, plan the move to 2.71.18 or later, since the advisory shows no patched version in those lines.
- Review session and authentication logs for accounts that logged in with a single factor despite having MFA enrolled, and revoke active sessions for any that look wrong.
- Keep a record of which services depend on the session API so the next advisory is quicker to scope.
Why it matters
The record lists CWE-287, improper authentication, and CWE-308, use of single factor authentication. The logic error is easy to state. The server only required more than one factor when a policy flag demanded it. A user who had enrolled MFA voluntarily was still allowed through on one factor.
That matters because the strongest argument for MFA is that a stolen password alone is not enough. The advisory points out the reverse risk: an attacker could aim at the six digit TOTP code alone and skip the password. Combined with weak brute force limits, as in CVE-2025-64102, that gets worse. The patch makes a configured second factor mandatory. This CVE is not marked as a CISA Known Exploited Vulnerability in the record.
Quick check
Do I need MFA required by policy to be exposed?
No. The issue concerned users who had set up MFA while the policy did not require it. Those sessions were accepted with a single factor.
Which fix applies to the 3.x line?
3.4.3 is the fixed release for 3.x. For 4.x use 4.6.0, and for 2.x use 2.71.18.
Sources
Last reviewed: 18 October 2026.
