CVE-2026-14781: Keycloak OIDC Email Verification Bypass & Account Takeover Risk

Technical summary

The vulnerability exists in org.keycloak.broker.oidc where email claim synchronization lacks proper validation. Specifically, when trustEmail=true and userinfo is enabled, the code retrieves the email address from the userinfo endpoint response but obtains the email_verified status exclusively from the id_token without cross-referencing whether the verified claim actually applies to the userinfo email. The flaw is the absence of a check confirming that the email address in the id_token's email_verified claim matches the email address returned by userinfo. An attacker controlling the upstream OIDC provider can craft a response where userinfo contains email A (marked unverified in id_token) while id_token contains email B (marked as email_verified=true), causing Keycloak to apply the verified status to email A in its database. CWE-1288 (Improper Validation of Consistency within Related Data) describes this root cause.

Business impact

Organizations using Keycloak with federated identity providers may find email-based security controls circumvented. If an application relies on the email_verified flag from an OIDC IdP to automatically link accounts or grant access, an attacker exploiting this flaw can establish or take over accounts using arbitrary email addresses marked as verified. The impact is most severe in environments where email domain belongs to the organization (company.com) or where email is the primary account identifier. Organizations using Keycloak for employee or customer identity federation should assess their email verification workflows.

Affected systems

Red Hat build of Keycloak is affected. The flaw requires non-default configuration (trustEmail=true on the OIDC identity provider) combined with a standard feature (userinfo endpoint enabled by default). Installations where trustEmail is not explicitly set to true are not vulnerable. Organizations should audit their OIDC broker configurations to identify which providers have trustEmail=true enabled.

Exploitability

Exploitation requires an attacker to control or compromise the upstream OIDC identity provider. An attacker cannot trigger this flaw from a downstream application; they must have the ability to craft the userinfo response and id_token from the IdP itself. This significantly constrains exploitability in scenarios where the IdP is a trusted third-party service (like an enterprise SSO system or major cloud provider). However, in federated multi-tenant or partner scenarios where organizations configure custom or partner-operated OIDC providers, the risk increases. The CVSS score of 4.8 (MEDIUM) reflects these limited but realistic attack conditions.

Remediation

Remediation involves validating that the email address in the id_token's email_verified claim matches the email address returned by the userinfo endpoint before applying the verified status. Until a patch is available, organizations should disable trustEmail on OIDC identity providers where the upstream provider is not fully under their control, or disable the userinfo endpoint if it is not required. For critical deployments, consider implementing additional email verification logic at the application level rather than relying solely on the IdP claim.

Patch guidance

Monitor Red Hat security advisories for a Keycloak patch addressing this vulnerability. When available, apply the patch to affected Keycloak instances. Test in a non-production environment first, particularly if custom OIDC providers or broker configurations are in use. Organizations should verify against the official Red Hat Keycloak security advisory for exact patched versions and migration steps.

Detection guidance

Review Keycloak OIDC identity provider configurations to identify any with trustEmail=true. Examine audit logs for suspicious account creation or linking events, particularly those involving email addresses from external domains or unexpected account takeover attempts. Monitor for cases where an account is created with an email address marked as verified immediately upon login, especially if that email differs from the authenticated user's expected address. Cross-reference Keycloak user accounts with upstream OIDC provider logs to identify discrepancies in email claims.

Why prioritize this

This vulnerability should be prioritized for organizations running Keycloak with federated OIDC providers, particularly those with trustEmail=true and relying on email verification for account linking or access control. While the CVSS score is MEDIUM and exploitability is constrained to compromised IdPs, the business impact of email verification bypass and account takeover is significant. Priority should be highest for multi-tenant or partner federation scenarios. Organizations using only trusted, controlled OIDC providers (internal SSO systems) may deprioritize slightly, but should still remediate.

Risk score, explained

CVSS 4.8 (MEDIUM) reflects a low attack vector (network-accessible but IdP compromise required), high attack complexity (attacker must control upstream provider), no privileges or user interaction needed, and limited impact scope. The integrity impact (ability to modify email_verified status) and confidentiality impact (potential to access accounts) justify the MEDIUM rating rather than LOW. The score would be higher if exploitation required only downstream application control, but the requirement to compromise the IdP constrains it.

Frequently asked questions