EUVD-2026-41732
GHSA-c96p-56gh-3pvw
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
AV:N reflects network-delivered OIDC flow; AC:H captures the hard prerequisite of controlling the upstream identity provider; PR:N as attacker holds no Keycloak privileges; C:L/I:L for email-flag integrity manipulation with downstream account-linkage risk.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token's email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default).
The userinfo endpoint must be enabled (default).
The attacker must control or have compromised the upstream OIDC provider.
Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database.
Bypass email-based security controls or verification workflows.
Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts.
AnalysisAI
Keycloak's OIDC broker incorrectly applies the email_verified claim from the id_token to whichever email address is returned by the userinfo endpoint, even when those two sources disagree. An attacker who controls or compromises an upstream OIDC identity provider can exploit this desynchronization - configured with trustEmail=true - to mark an arbitrary, attacker-chosen email address as verified in Keycloak's database. The practical consequence is bypassing email verification workflows or triggering account linkage/takeover in applications that trust the email_verified flag from Keycloak for identity decisions. No public exploit code exists and no CISA KEV listing applies at time of analysis.
Technical ContextAI
The flaw resides in the org.keycloak.broker.oidc package, which handles federated authentication through external OIDC identity providers. The OIDC specification provides two distinct claim sources: the id_token (a signed JWT returned at token issuance) and the userinfo endpoint (a separate HTTP resource). Keycloak's broker implementation fetches the email address from userinfo but reads the email_verified status exclusively from the id_token, with no cross-validation confirming the two sources reference the same email address. This is classified under CWE-1288 (Improper Validation of Consistency within Input) - a logic flaw where data from two coordinated inputs is consumed without verifying their mutual consistency. Affected CPE strings confirm impact across Red Hat Build of Keycloak, Red Hat Single Sign-On 7, Red Hat Data Grid 8, and Red Hat JBoss EAP Expansion Pack (all versions per cpe:2.3:a:red_hat:* wildcards reported by Red Hat). The vulnerability exists only when the trustEmail=true flag is explicitly set on the identity provider configuration, a non-default setting that must be deliberately enabled by an administrator.
RemediationAI
Consult the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-14781 and the associated Bugzilla tracker at https://bugzilla.redhat.com/show_bug.cgi?id=2497118 for patched release versions - no specific fix version was confirmed in the available intelligence data at time of analysis. As an immediate compensating control, set trustEmail=false on all OIDC identity provider configurations in Keycloak; this forces Keycloak to treat incoming email addresses as unverified regardless of the id_token claim, neutralizing the attack vector entirely at the cost of requiring users to complete email verification within the application. A second compensating control is to disable the userinfo endpoint on the OIDC broker configuration, forcing Keycloak to source all claims solely from the id_token and eliminating the split-source desynchronization. Additionally, review all OIDC identity provider configurations with trustEmail=true and restrict those integrations to identity providers under organizational control where provider compromise risk is managed. Apply principle of least trust: do not rely solely on email_verified from an external IdP to drive account linking decisions.
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Open redirect in Red Hat build of Keycloak permits remote attackers to send victims to attacker-controlled hosts by abus
Same technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today