Upgrade Zulip Server to 12.2 to Stop Account Takeover via Identity Provider Flaw

Zulip Server versions prior to 12.2 contain a critical authentication vulnerability that allows attackers to take over user accounts. The flaw exists in how the software processes identity provider responses during login. According to the National Vulnerability Database, this issue is rated 9.1 on the CVSS scale, indicating a severe risk to any deployment using single sign-on features.

An attacker who controls a misconfigured identity provider can trick the system into logging them into an existing Zulip account. The software matches the email address provided by the identity provider to an active user account. It fails to reject the login attempt even when the identity provider explicitly states that the email address has not been verified. This allows unauthorized access without needing the user’s password.

Authentication Logic Failure

The vulnerability stems from a flaw in the GenericOpenIdConnectBackend component of Zulip Server. This component handles the exchange of identity data between the server and external identity providers. When a user attempts to log in, the system checks the email address claim returned by the provider. The code compares this address to the delivery_email of existing accounts. If a match is found, the system grants access.

The critical error occurs because the system ignores the email_verified claim. Even if the identity provider sets this flag to false, indicating the user does not control the email, Zulip proceeds with the login. This behavior violates standard security practices for identity federation. It assumes that a matching email address is sufficient proof of identity, disregarding explicit verification status signals from trusted sources.

Affected Deployments

Only Zulip Server installations running versions earlier than 12.2 are vulnerable to this specific attack vector. The National Vulnerability Database confirms that the fix was included in version 12.2. Organizations that have not yet upgraded remain exposed to potential account takeover. The risk depends entirely on the configuration of the identity providers linked to the Zulip instance.

Deployments are not affected if their authoritative identity provider only emits email addresses that are actually controlled by the authenticating user. In such cases, even if the email_verified claim is false, the attacker cannot supply a valid but uncontrolled email for an existing victim. However, if a trusted identity provider is misconfigured to return unverified or arbitrary email addresses, the flaw becomes exploitable. This creates a scenario where trust in the provider is misplaced by the application logic.

What to watch

Administrators should immediately verify the version of their Zulip Server installation. If the version is below 12.2, they should prioritize upgrading to the patched release. Once the vendor provides an update, testing the upgrade in a staging environment is recommended to ensure compatibility with existing integrations. Teams should also review their identity provider configurations to ensure they are not returning unverified email claims for authenticated users.

What made it possible

This incident highlights the risks of trusting external identity assertions without strict validation. Authentication systems often rely on identity providers to confirm user identity. When applications accept claims like email addresses without verifying their validity status, they create bypass opportunities.

Attackers exploit this by supplying data that matches existing records but lacks proper verification. Security teams usually implement strict claim validation rules. Check whether your systems enforce verification flags from identity providers. Ensure that unverified claims trigger rejection rather than acceptance. This prevents unauthorized access through misconfigured or malicious identity sources.

Background: Account takeover

Account takeover occurs when an attacker gains unauthorized access to your credentials. It rarely involves complex hacking. Instead, attackers use stolen data, social engineering, or session flaws to impersonate you. Securing the login flow and verifying identity changes prevents most of these intrusions.

Read the full guide: Account Takeover: How Attackers Bypass Login Security

What to do and how to stay safe: Zulip

• Verify your current Zulip Server version and upgrade to 12.2 or later if you are running an older release.
• Review the configuration of all connected identity providers to ensure they are returning accurate email verification status.
• Monitor authentication logs for unusual login patterns, such as successful logins from unexpected identity sources or with unverified claims.
• Educate users about the importance of using verified email addresses in their identity provider profiles to reduce exposure.

Step-by-step guide: How Security Advisories Drive Patch Decisions and Reduce Risk

General security guidance from the Shell Bulletin newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is CVE-2026-102893?

It is a critical vulnerability in Zulip Server versions before 12.2 that allows authentication bypass via unverified email claims from identity providers.

How severe is this vulnerability?

The National Vulnerability Database rates it as critical with a CVSS score of 9.1.

Is there a fix available?

Yes, the issue is fixed in Zulip Server version 12.2.