A flaw was found in Keycloak. The Keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy. The issue occurs at least via ha-proxy, as it can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms which is expected to be exposed.

Improper input validation vulnerability in Keycloak related to the handling of matrix parameters in URL paths. The issue occurs because Keycloak, via its JAX-RS routing layer, accepts RFC-compliant matrix parameters (e.g., ;param) in path segments, while common reverse proxy configurations may ignore or mishandle them when enforcing access restrictions. A remote attacker can craft requests such as /realms;abc/master/account to mask path segments and bypass proxy-level path filtering. Although authentication is still required, this may expose administrative or sensitive endpoints that operators believe are not externally reachable. Exploitation is network-based, requires no authentication, and depends on the reverse proxy configuration in front of Keycloak.

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KCRESTART cookie returned by the authorization server's HTTP response to a requesturi authorization request. This could lead to an information disclosure vulnerability.

An incomplete fix for CVE-2026-9689 was identified in Keycloak's RedirectUtils.containsForbiddenOidcParameters() method. While the original fix successfully blocks forbidden OIDC parameters (such as code, state, and iss) in the URI query string, it fails to inspect the URI fragment (#). When a client is configured with a wildcard redirect URI, an attacker can supply a redirecturi containing these forbidden parameters within the fragment. Because matchesRedirects strips fragments during prefix matching, the crafted URI is accepted. During the authorization response, Keycloak appends its own parameters to the attacker-supplied fragment, leading to a polluted response where attacker-controlled values appear first. Exploitation Conditions: The target client must have a wildcard-registered redirect URI (e.g., https://app.example.com/).

The attacker must induce a victim to follow a crafted authorization URL.

The relying party (client application) must use a first-wins parsing strategy for duplicate parameters.

Concrete Impact: Injection of attacker-controlled iss (issuer), state, and accesstoken parameters.

Potential for session fixation or account confusion if the relying party does not validate parameters per RFC 9207.

A flaw was found in Keycloak’s CIBA feature where insufficient validation of client-configured backchannel notification endpoints could allow blind server-side requests to internal services.

CORS header injection vulnerability in Keycloak’s UMA token endpoint. The flaw is caused by reading the azp claim from a client-supplied JWT to set the Access-Control-Allow-Origin header before the JWT signature is validated. When a specially crafted JWT with an attacker-controlled azp value is processed, that value is reflected as the CORS origin even though the grant is later rejected. This can be exploited remotely without authentication when a target client is misconfigured with webOrigins: [""]. Attackers can then read UMA error responses cross-origin, weakening origin isolation and exposing low-sensitivity information from the authorization server.

A flaw was found in Keycloak Admin REST (Representational State Transfer) API. This vulnerability allows information disclosure of sensitive role metadata via insufficient authorization checks on the /admin/realms/{realm}/roles endpoint.

A flaw was found in the Keycloak server during refresh token processing, specifically in the TokenManager class responsible for enforcing refresh token reuse policies. When strict refresh token rotation is enabled, the validation and update of refresh token usage are not performed atomically. This allows concurrent refresh requests to bypass single-use enforcement and issue multiple access tokens from the same refresh token. As a result, Keycloak’s refresh token rotation hardening can be undermined.

A flaw was found in Keycloak. A remote attacker can exploit differential error messages during the identity-first login flow when Organizations are enabled. This vulnerability allows an attacker to determine the existence of users, leading to information disclosure through user enumeration.

A vulnerability was found in Keycloak. This issue may allow a privileged attacker to use a malicious payload as the permission while creating items (Resource and Permissions) from the admin console, leading to a stored cross-site scripting (XSS) attack.

Blind SSRF behavior in the CIBA implementation of Keycloak. The issue arises because the backchannelclientnotificationendpoint configured during Dynamic Client Registration or client administration is not sufficiently validated before use. An attacker with high privileges (Administrator access or a valid Initial Access Token) can configure this endpoint to point to arbitrary internal URLs, including localhost or cloud metadata services. When a CIBA authentication request is initiated in ping mode, Keycloak sends a blind POST request to the configured endpoint. While the attacker cannot observe the response, the behavior allows limited influence over server-side network interactions and may enable abuse of internal services.

An Improper Access Control vulnerability exists in the Keycloak Admin REST API, where a user possessing only the create-client permission—considered low-privilege by design—can unexpectedly access the /admin/realms/master/users/profile endpoint. This endpoint returns internal user profile schema data, including attribute names, validation rules, display metadata, and permission mappings. Although the attacker cannot view actual user accounts, the exposure of backend schema and rules results from insufficient authorization checks specifically on this endpoint. An authenticated but minimally privileged user can remotely retrieve sensitive configuration metadata, which may be leveraged to craft targeted attacks or prepare future privilege-escalation attempts.

A flaw was found in Keycloak 7.0.1. A logged in user can do an account email enumeration attack.

References: https://issues.jboss.org/browse/KEYCLOAK-12014

/clients-registrations/openid-connect could consume an invalidated token and register a new client.

Reproducer: 1. Generate a token for service-account using the clientcredentials flow 2. Revoke the token using the /revoke endpoint passing in the above token. 3. Now, invoke /clients-registrations/openid-connect passing in the above generated token for auth 4. A client is created using the token

Low: Red Hat build of Keycloak 22.0.11 enhancement and security update

Low: Red Hat build of Keycloak 22.0.11 Images enhancement and security update

Low: Red Hat build of Keycloak 24.0.5 Images enhancement and security update

Low: Red Hat build of Keycloak 24.0.5 enhancement and security update