CVE-2026-7507

A flaw in the Device Authorization Grant flow of Keycloak occurs because the token redemption process fails to check whether a user account is currently locked due to brute-force protection. If an attacker has an active session for a locked account, they can complete the device login process and receive new security tokens.

A flaw was found in the group policy provider of Keycloak authorization services, which is used to manage fine-grained access control to resources. The issue occurs when the system evaluates group-based policies using tokens that only contain group names rather than full paths. If two groups in different parts of the organization share the same name, a user in the unauthorized group can be mistaken for a member of the authorized group. This can allow a user to gain unauthorized access to protected resources they should not be able to reach.

A flaw was found in Keycloak regarding the authorization header parser. This parser is overly permissive regarding the formatting of the 'Bearer' authentication scheme, accepting non-standard characters as separators and tolerating case variations that deviate from RFC 6750 specifications.

It was found that the cookie used for CSRF prevention in Keycloak was not unique to each session. An attacker could use this flaw to gain access to an authenticated user session, leading to possible information disclosure or further attacks.

A flaw was found in the first-broker-login flow of the Keycloak identity management service. When a user links a social identity provider account to their local account, the verification proof generated is not strictly bound to the specific upstream identity being verified. This allows an attacker with a different account on the same social provider to intercept the process and link their own account to the victim's local profile, gaining unauthorized access.

A flaw was found in the JWT Bearer authorization grant implementation within the keycloak-services component of Red Hat Build of Keycloak. The grant fails to check if a client requires user consent before issuing a token. This allows an authenticated attacker with valid client credentials and a trusted identity provider assertion to bypass the consent requirement and obtain unauthorized access to a user account at a consent-gated client.

Keycloak contains a vulnerability in the legacy account-linking endpoint, where the protection mechanism based on a hash can be predicted by a malicious OIDC client. An attacker can forge a linking URL to connect the victim's account to an attacker-controlled external identity, leading to full account takeover.

In the SAML broker component of Keycloak, when configured with IdP-Initiated flow, the OneTimeUse condition in SAML assertions is not enforced. This allows an attacker who captures a valid, unused assertion to replay it multiple times, potentially hijacking a user's session.

A flaw in the SAML broker component of Keycloak, used for identity federation and user authentication. The IdP-initiated Single Sign-On endpoint fails to check if a provider is restricted to account linking only, allowing an attacker with control over a linked upstream identity to bypass login restrictions and gain full access to a local user account.

A flaw in Keycloak's Dynamic Client Registration (DCR) security policy management. The "Allowed Protocol Mapper Types" policy fails to re-validate the mapper type during a client update if the mapper's configuration remains unchanged. An attacker with client registration privileges can register an allowed mapper type with malicious configuration and then swap it for a restricted, high-privilege mapper type, gaining full administrative access to the realm.