Red Hat Keycloak CVE-2026-14781

Exploitation requires two non-trivial preconditions to be simultaneously satisfied. First, the OIDC identity provider configuration in Keycloak must have trustEmail set to true - this is explicitly a non-default setting that must be manually enabled by an administrator, meaning deployments with default configurations are not affected. Second, the attacker must control or have compromised the upstream OIDC identity provider itself - they must be capable of returning crafted, divergent claim values from the token endpoint (id_token) versus the userinfo endpoint. The userinfo endpoint must be enabled on the broker, which is the default state. Exploitation is limited to scenarios where Keycloak federates with external or third-party OIDC providers; internal-only deployments where the IdP is fully under organizational control have substantially reduced exposure because provider compromise would already be a critical security event. Authentication to Keycloak itself is not required by the attacker; the attack operates through the federated identity flow. No attacker privileges within Keycloak are needed.

The CVSS 3.1 score of 4.8 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N is broadly consistent with the actual risk profile. The AC:H rating reflects the most significant real-world barrier: the attacker must control or have compromised the upstream OIDC identity provider, which is a high-privilege precondition that substantially limits the exploitable population. The PR:N rating is technically correct - the attacker holds no Keycloak privileges - but the implicit requirement to operate a malicious or compromised OIDC provider is a significant operational constraint not fully captured in the base vector. No EPSS score data was provided in the intelligence sources. There is no CISA KEV listing and no public proof-of-concept, indicating no confirmed active exploitation. The real-world priority classification depends heavily on deployment context: organizations federating Keycloak with third-party or external OIDC providers with trustEmail=true face meaningful account-takeover risk; organizations using only internal or trusted IdPs where provider compromise is already a critical incident face lower incremental risk from this specific flaw. The C:L/I:L ratings understate potential downstream impact in scenarios where email_verified drives account linking - in those architectures, account takeover is achievable, representing a more severe practical outcome than Medium CVSS implies.

An attacker who controls a malicious (or has compromised a legitimate) upstream OIDC provider configured as an identity provider in a Keycloak deployment with trustEmail=true crafts authentication responses where the id_token contains email_verified=true for attacker@attacker.com, while the userinfo endpoint returns the email of a victim user, victim@organization.com. When a login flow is processed, Keycloak retrieves victim@organization.com from userinfo and blindly applies the email_verified=true from the id_token, permanently marking victim@organization.com as verified in the Keycloak database. If the relying application uses this verified email to link or elevate the account, the attacker gains access to the victim's application identity.