Zulip Server EUVD-2026-101287

Requires the Zulip server to be configured with GenericOpenIdConnectBackend (OIDC single sign-on) AND the configured trusted identity provider to be misconfigured such that it returns an email address the authenticating user does not control together with an explicit email_verified=false claim. The key limiting factors: OIDC SSO must be enabled; the authoritative IdP must emit email addresses not owned by the authenticating user - deployments whose IdP only emits user-controlled emails are explicitly not affected; and a target account with a matching delivery_email must already exist. This is a server-side/operator misconfiguration precondition outside the attacker's direct control (reflected as AT:P in the 4.0 vector), not a flaw triggerable against a correctly configured default OIDC deployment.

The input CVSS 4.0 base score is 9.1 (Critical) with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N, and the weakness is an authentication bypass (CWE-287). The single most important signal is AT:P (Attack Requirements: Present), which the vendor uses to encode the explicit precondition that the deployment must run GenericOpenIdConnectBackend behind a misconfigured or untrustworthy identity provider - the description states deployments whose IdP only emits user-controlled email addresses are NOT affected. This materially lowers real-world risk below what the headline 9.1 implies: although PR:N/UI:N suggest trivial remote unauthenticated takeover, exploitation is gated on an attacker-uncontrollable server-side misconfiguration. No EPSS score was provided in the input, there is no CISA KEV listing, and no public proof-of-concept was supplied - so exploitation status is: no public exploit identified at time of analysis. A patch is confirmed available (12.2) and the fix commit/diff is public, which raises the theoretical likelihood of exploit development over time, but the conditional precondition keeps this closer to a targeted/niche issue than a mass-exploitable one. Net: treat as a high-priority patch for any Zulip deployment that uses OIDC SSO, but a non-issue for deployments not using GenericOpenIdConnectBackend or whose IdP is correctly configured. Conflicting-signal note: the raw CVSS vector reads as easy remote unauth exploitation, but the AT:P flag and the description's precondition should be read together as a significant real-world limiter - verify your IdP's email_verified behavior rather than relying on the 9.1 alone.

A Zulip server is configured with a single trusted OpenID Connect provider that is misconfigured to emit arbitrary email addresses with email_verified=false. An attacker who can obtain any account on (or influence) that IdP causes it to assert a victim's email address with email_verified=false; because Zulip (≤12.1) matched the email claim to an existing account's delivery_email without rejecting the false verification claim, the attacker is logged straight into the victim's Zulip account. No public exploit code was provided in the input, but the fix diff is publicly visible in the GitHub commits and GHSA advisory.