CVE-2026-117627 in Keycloak
Summary
by MITRE • 10/29/2026
A flaw was found in the JWT Authorization Grant implementation of the keycloak-services component. When an OIDC or Google identity provider is configured with specific login restrictions, such as claim filtering, these checks are correctly applied during standard browser logins but are skipped during the JWT-based grant flow. This allows an authenticated client to obtain access tokens for a user even if their identity provider claims should have blocked the login.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in the keycloak-services component represents a critical authentication bypass within the JSON Web Token (JWT) Authorization Grant implementation, specifically affecting configurations that utilize OpenID Connect or Google as external identity providers with restrictive claim filtering policies. In standard web-based interactions involving browser redirects and implicit flows, Keycloak correctly enforces configured login restrictions by validating user claims against defined allowlists or denylists before issuing tokens. However, the JWT bearer token flow operates through a different code path that fails to replicate these essential validation checks. This architectural inconsistency creates a significant security gap where the system assumes trust based on the presence of a valid access token from an upstream provider without re-evaluating whether the specific user attributes meet the local policy requirements for service access.
From a technical perspective, this flaw stems from a lack of centralized claim verification logic across different grant types within the authentication engine. When a client application presents a JWT to Keycloak requesting a new access token via the authorization grant flow, the system processes the request by validating the signature and expiration of the incoming token but neglects to apply the identity provider's configured restrictions such as email domain filtering or role-based claim matching. Consequently, any user who possesses a valid authentication session with an external IdP that has been restricted can exploit this oversight to obtain service tokens for applications they should not be able to access. This behavior effectively nullifies the security controls intended to limit access based on identity attributes, rendering configurations like email domain whitelists or specific group memberships ineffective in API-driven contexts.
The operational impact of this vulnerability is severe, particularly in environments where Keycloak serves as an Identity and Access Management provider for microservices or APIs that rely heavily on JWT-based authentication rather than traditional browser sessions. An authenticated attacker with access to a compromised account from an external identity provider can bypass administrative restrictions designed to prevent unauthorized users from logging into specific services. This leads directly to unauthorized data exposure, privilege escalation within the application layer, and potential lateral movement if the accessed service has higher privileges or connectivity to sensitive internal resources. The risk is amplified in multi-tenant environments where strict isolation between user groups based on identity claims is a primary security requirement.
This vulnerability aligns with CWE-287 Improper Authentication because it involves a failure to correctly verify authentication credentials against established policies, and CWE-613 Insufficient Session Expiration which may be exacerbated if the bypass allows prolonged unauthorized access. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1078 Valid Accounts as an attacker leverages legitimate but restricted accounts to gain initial foothold or persistence, and potentially T1528 Steal Application Access Token if the goal is to harvest tokens for further exploitation without triggering standard alerting mechanisms associated with failed login attempts. The core issue lies in the inconsistent application of security policies across different authentication flows within the same identity provider infrastructure.
To mitigate this risk, administrators must immediately upgrade keycloak-services to a version where the JWT Authorization Grant flow includes parity with browser-based flows regarding claim validation and restriction enforcement. Until an official patch is applied, organizations should consider disabling the JWT bearer token grant type for any clients that require strict adherence to external identity provider restrictions or implement reverse proxy rules that validate user claims at the network edge before they reach Keycloak. Additionally, auditing logs for unusual patterns of token issuance from restricted users can help identify potential exploitation attempts in real-time while monitoring configurations ensures that no new services are provisioned with overly permissive grant types until the underlying flaw is resolved.