CVE-2026-55075: Coder OIDC Account Takeover – Email Verification Bypass

Technical summary

The vulnerability chain involves two distinct flaws in Coder's OIDC implementation: First, email-based user matching as a fallback mechanism does not validate whether an email address is already linked to a different IdP (identity provider) subject identifier, allowing an attacker to claim ownership of an email tied to an existing account. Second, the `email_verified` claim enforcement is inconsistent—the system only treats the claim as authoritative when explicitly set to boolean `false`; when the claim is absent or non-boolean, it defaults to treating the email as verified. These flaws chain because an attacker controlling an OIDC provider can omit or misformat the `email_verified` claim while providing a victim's email address, causing the system to match the incoming login to an existing account via email fallback without properly verifying the email's legitimacy. The fix constrains email fallback linking to first-time and legacy account linking scenarios only, and defaults `email_verified` to `false` when the claim is absent or malformed, enforcing explicit verification.

Business impact

Account takeover via this vector could allow unauthorized actors to access sensitive remote development environments, potentially exposing source code, credentials, secrets, and intellectual property stored within those environments. For organizations using Coder as a central development platform, a successful exploit could lead to supply chain contamination, lateral movement into connected infrastructure, compliance violations, and reputational damage. The HIGH CVSS score (7.4) reflects the combination of network accessibility and high integrity/confidentiality impact, though exploitation requires moderate technical skill (AC:H) and is not currently in active widespread exploitation.

Affected systems

Coder versions prior to 2.29.7, 2.32.7, 2.33.8, and 2.34.2 are affected. Organizations using Coder for remote development environment provisioning should immediately verify their deployed version. The vulnerability only manifests when OIDC login is configured; Coder instances using alternative authentication methods (password-based, SAML, or other mechanisms) are not directly exploitable via this chain.

Exploitability

Exploitation requires an attacker to either control or compromise an OIDC provider, or trick an organization into integrating a malicious OIDC provider. The attacker must then craft a login request using the victim's email address and carefully omit or misformat the `email_verified` claim to trigger the fallback matching behavior. This is not a trivial attack—it requires knowledge of the target's email and control over an OIDC provider—but is achievable in scenarios where an attacker can set up a rogue provider or has compromised a less-protected OIDC endpoint. The fact that the vulnerability is not yet in the KEV catalog suggests active exploitation is not yet documented in the wild, but the architectural weakness makes it a high-priority fix.

Remediation

Patch to Coder versions 2.29.7, 2.32.7, 2.33.8, or 2.34.2 depending on your release track. If immediate patching is not feasible, configure your OIDC provider to disallow self-registration or require email verification before issuing tokens—this mitigates the risk by preventing an attacker from claiming unverified email addresses. Additionally, audit your OIDC provider integrations and ensure they enforce strict email verification policies and do not allow arbitrary claim manipulation.

Patch guidance

Identify your current Coder version and determine which fixed release is appropriate for your deployment. Versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 contain the fix; apply the corresponding patch for your release branch. Test the upgrade in a non-production environment first to verify OIDC login functionality remains intact. After patching, review your OIDC provider configuration to confirm email verification is enabled and enforced. Plan this update as a priority but not as an emergency hotfix if you currently have OIDC self-registration disabled.

Detection guidance

Monitor OIDC login logs for suspicious patterns: multiple login attempts using the same email address from different IdP subjects, failed email verification claims, or logins from newly registered OIDC providers. Implement alerting on account access events that follow anomalous OIDC authentication patterns. Review audit logs for any unexpected account takeovers or privilege escalations following OIDC login events. If available, enable verbose logging on your OIDC provider integration to capture claim details and trace email fallback matches.

Why prioritize this

This vulnerability merits HIGH priority because it enables direct account takeover of development infrastructure with HIGH impact on confidentiality and integrity. Although exploitation requires moderate technical complexity and is not yet in active exploitation, the risk to development environments—which often contain secrets, source code, and credentials—justifies rapid patching. Organizations with OIDC-based access control and those handling sensitive intellectual property should patch within 30 days.

Risk score, explained

CVSS 3.1 score of 7.4 reflects: Network Attackability (AV:N), High Complexity due to attacker needing OIDC provider control (AC:H), No Privilege Required (PR:N), No User Interaction needed (UI:N), impact scope unchanged (S:U), High Confidentiality impact (access to environments and secrets), High Integrity impact (ability to modify development artifacts), and No Availability impact (A:N). The score appropriately captures a serious but not critical vulnerability requiring defensive action but not causing immediate system failure.

Frequently asked questions