CVE-2026-55076: Coder OIDC Authentication Bypass and Account Takeover

Technical summary

The vulnerability exists in Coder's OIDC callback handler, which uses Go's direct type assertion to check the `email_verified` boolean claim. Type assertions in Go fail catastrophically when the underlying type does not match; if an IdP sends `email_verified` as a JSON string (e.g., `"false"`) or as a number, or if the claim is absent, the assertion panics or returns a false boolean value that is then mishandled. Rather than rejecting the login or prompting additional verification, the code treats the email as verified. The second vulnerability lies in the email-fallback linking logic: if no existing IdP subject (sub claim) matches the incoming user, Coder falls back to linking accounts by email address alone, without confirming that the user already has a different IdP linked. An attacker can exploit this by registering a user account at a malicious or compromised IdP, setting an email address that matches a target user at the legitimate organization, and bypassing the email verification check to gain access. The fix coerces the `email_verified` claim across multiple types (bool, string, numeric) with fail-closed semantics and prevents email-based account linking when a user already has a different IdP subject linked.

Business impact

Account takeover of Coder users represents a direct compromise of development infrastructure access. An attacker who gains control of a developer or administrator account can access, modify, or exfiltrate code repositories, intellectual property, and secrets stored within remote development environments. In regulated industries, such breaches trigger compliance violations, incident notification obligations, and potential fines. For software development organizations, the risk extends to supply chain integrity: a compromised developer account is a foothold for injecting malicious code into production systems. The attack requires no user interaction or social engineering—only knowledge of a target's email domain and control of an OIDC provider, making it a high-impact, low-friction threat.

Affected systems

Coder versions prior to 2.29.7, 2.32.7, 2.33.8, and 2.34.2 are affected. Organizations using Coder with OIDC-based single sign-on are at direct risk. The vulnerability is most exploitable in scenarios where: (1) the IdP returns `email_verified` in a non-standard format or omits it; (2) user email addresses are predictable or public (e.g., [email protected]); and (3) the organization relies on email as the primary identifier for account linking. On-premises and SaaS deployments are equally vulnerable.

Exploitability

Exploitability is moderate to high, contingent on attacker access to an OIDC provider. An attacker does not need to compromise the legitimate organization's IdP; they can register an account at a public OIDC provider (such as Google, GitHub, or a custom provider they control), set the target's email address, and attempt to log in to Coder. The attack succeeds if Coder has not been patched and the IdP's response contains a non-boolean `email_verified` claim or omits it. No special privileges, user interaction, or network access to the victim's infrastructure are required. The CVSS score of 7.4 reflects high impact (confidentiality and integrity of accounts) balanced against the requirement that the attacker must have control of or the ability to register at an OIDC provider, which raises the attack complexity.

Remediation

Upgrade Coder to version 2.29.7, 2.32.7, 2.33.8, or 2.34.2 or later, depending on your current branch. The patches implement proper type coercion for `email_verified` and block email-fallback linking when a user already has a different IdP subject registered. As a temporary workaround for organizations that cannot patch immediately, ensure your OIDC identity provider returns `email_verified` as a native JSON boolean (not a string or numeric type). However, this workaround does not address the email-fallback linking issue, so patching remains mandatory for complete remediation.

Patch guidance

Identify your current Coder version and branch. Users on the 2.29.x branch should upgrade to 2.29.7 or later; 2.32.x users should upgrade to 2.32.7 or later; 2.33.x users should upgrade to 2.33.8 or later; and 2.34.x users should upgrade to 2.34.2 or later. Verify patch versions against the official Coder release notes to confirm availability in your deployment model. Apply patches during a maintenance window and restart all Coder services. No database migration is required. After patching, test OIDC authentication flows with your IdP to confirm proper functionality.

Detection guidance

Monitor OIDC authentication logs for unusual patterns: failed `email_verified` type assertions (if logging is enabled), successful logins from unexpected IdPs or IP ranges associated with the target user's email, and login events where the IdP subject (sub claim) differs from previous sessions for the same user. Check Coder audit logs for account linking events, particularly those triggered by email fallback when a different IdP subject was previously registered. Correlate Coder authentication logs with your IdP logs to identify cases where an attacker attempted to register a user account with a target's email address at an external or suspicious IdP. Inspect OIDC token responses in transit (via network monitoring or IdP logs) to confirm that `email_verified` is returned as a boolean; non-standard formats indicate misconfiguration or tampering.

Why prioritize this

This vulnerability should be prioritized for immediate patching because it enables direct account takeover of developer accounts with no user interaction required. The impact—unauthorized access to development environments, code, and secrets—is severe, and the barrier to exploitation is low. The fact that it is not yet listed on the CISA Known Exploited Vulnerabilities (KEV) catalog does not diminish urgency; opportunistic attackers are likely to target this flaw once patches are deployed and the vulnerability is widely known. Organizations with publicly disclosed or easily guessable email formats are at higher risk.

Risk score, explained

The CVSS v3.1 score of 7.4 (HIGH) reflects a network-accessible vulnerability with high impact on confidentiality and integrity (account takeover) but no availability impact. The attack complexity is rated as high because the attacker must control or register at an OIDC provider and the IdP response must be non-standard or incomplete. However, this complexity is lower in practice for organizations that do not enforce strict IdP whitelisting or that accept OIDC connections from multiple providers. The absence of required privileges or user interaction keeps the score elevated; this is an unauthenticated flaw.

Frequently asked questions