Keycloak EUVD-2026-112636

Exploitation requires the target to have an OIDC or Google identity provider configured with login restrictions such as claim filtering - deployments without such IdP restrictions are not affected because there is no check to bypass. The attacker must be an authenticated client (PR:L) capable of using the JWT-based authorization grant flow; the standard browser login path correctly enforces the claims and is not the affected path. Impact is limited to obtaining tokens for users the IdP claims should have blocked, with low confidentiality and integrity impact and no availability impact.

This is a moderate-severity authorization bypass (CWE-862) rated CVSS 5.4 via CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. The network vector with low attack complexity and no user interaction makes the flaw easy to trigger, but PR:L means an attacker must already be an authenticated client, which meaningfully narrows the attacker population and caps impact at low confidentiality/integrity with no availability effect. No EPSS score was provided and there is no CISA KEV listing, so there is no signal of active exploitation; the vuln.today decision label is 'this_month' rather than act_now/emergency, consistent with a real but non-urgent issue. No SSVC decision breakdown (automatable, technical impact) was supplied. The practical risk is conditional: it only matters where an OIDC or Google identity provider is configured with login restrictions such as claim filtering, so this is a prioritize-within-the-month patch for affected Keycloak/RH-SSO deployments rather than a drop-everything CVSS-inflated issue. The signals are internally consistent - moderate CVSS, no exploitation evidence, mid-tier priority label all align.

In a Keycloak or Red Hat Single Sign-On deployment where an OIDC or Google identity provider is configured to restrict logins (for example, filtering on specific claims), an authenticated client uses the JWT Authorization Grant flow instead of a standard browser login. Because the claim-filtering checks are skipped on that code path, the client obtains access tokens for a user whose identity-provider claims should have blocked the login. No public exploit has been identified at time of analysis.