GHSA-992q-9gwp-7r79: Medium severity go/github.com/zitadel/zitadel vulnerability
Summary
A flaw in the external identity provider handler allows unauthorized account linking to occur under specific administrative configurations. When auto-linking by email is enabled, ZITADEL checks that the local user's email is verified, but does not explicitly cross-check whether the incoming external identity provider (IdP) also verified that email address upstream.
Impact
When a user logs in via an external identity provider, the system can automatically link them to an existing local account if their email addresses match. However, because the system fails to check if the external provider actually verified ownership of that email, a security risk is introduced if a loose or public provider is connected.
If an administrator enables email auto-linking for an external identity provider that allows anyone to sign up with an unverified email address, an attacker can exploit this behavior. By registering an account on that permissive provider using a victim's email address and logging in, the system will automatically link the attacker's federated identity to the victim's legitimate local account. This allows the attacker to log into the victim's account without requiring any interaction or confirmation from the victim.
This issue represents a configuration-dependent anomaly rather than an unconditioned attack vector. Because the scenario relies entirely on an explicit administrative choice to trust a permissive external directory and link accounts automatically based purely on email strings, the practical operational risk is classified as Medium.
Affected Versions
Systems running one of the following versions are affected:
4.x: 4.0.0 through 4.15.2 (including RC versions) 3.x: 3.0.0 through 3.4.12 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring that the external identity provider's email verification status is explicitly validated before allowing any automatic linking logic to proceed.
4.x: Upgrade to $\ge$ 4.15.3 3.x: Upgrade to $\ge$ 4.15.3
Workarounds
If an immediate upgrade is not possible, implement one of the following mitigations:
Disable auto-linking by email entirely by setting the option to AUTOLINKINGOPTIONUNSPECIFIED on corresponding identity providers. Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Android-Login-Analysis and Alejandro Yadlin for reporting this vulnerability.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/zitadel/zitadelto a version that resolves this vulnerability.Fixed in 4.15.3 - Upgrade
Upgrade
zitadel/zitadelto a version that resolves this vulnerability.Fixed in 4.15.3 - Configuration
Disable email auto-linking by email entirely by setting the option to AUTO_LINKING_OPTION_UNSPECIFIED on the corresponding identity providers.
ZITADEL external identity providers AUTO_LINKING_OPTION_UNSPECIFIED = set - Compensating control
Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy.
Event History
Frequently Asked Questions
Which deployments are exposed to account takeover through this issue?
Deployments are exposed when email auto-linking is enabled for an external identity provider that permits users to register with email addresses that the provider has not verified. The risk is tied to that administrative configuration rather than every external identity provider integration.
What does an attacker need to exploit it?
An attacker needs access to a connected permissive or public identity provider where they can create an account using a victim's email address without proving ownership. They can then sign in through that provider and trigger automatic linking to the matching local account.
What can be done if patching is not immediately possible?
Disable email-based auto-linking for external identity providers, particularly providers that do not verify email ownership upstream. Do not enable this feature for providers that allow unverified email registration.
How can administrators determine whether they may be affected?
Review external identity provider configurations for email auto-linking and identify whether any connected provider accepts unverified email addresses during registration. Any such provider combined with enabled auto-linking creates the described exposure.