Description

A flaw was found in the Admin REST API of Keycloak, an identity and access management solution. The Admin API fails to verify the intended audience of bearer tokens during authentication. This issue allows an attacker who operates a client within a realm to capture an administrator's access token and reuse it to perform unauthorized administrative actions, potentially leading to full realm compromise.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-11-06T06:16:42.687Z",
  "pubdate": "2026-11-06T06:16:42.687Z",
  "executiveSummary": "The Admin REST API in Keycloak contains an authentication bypass vulnerability stemming from a failure to validate the 'aud' (audience) claim within bearer tokens. This flaw allows an authenticated client user within a realm to perform a cross-service impersonation attack. By intercepting a valid access token issued for one service, an attacker can present that token to the Admin API to authenticate as an administrator. The impact is significant, as it enables unauthorized administrative actions, potentially leading to full administrative compromise of the target realm. The vulnerability poses a high risk to identity environments where multiple services rely on Keycloak for authorization, as it effectively nullifies the scope restrictions intended by the OIDC and OAuth 2.0 specifications. Exploitation requires the attacker to be a valid, authenticated client within the same realm, placing it in the category of privilege escalation via token misuse.",
  "technicalDetails": "The vulnerability resides in the validation logic of the Keycloak Admin REST API. When processing incoming requests protected by bearer tokens, the API fails to verify the 'aud' (audience) field, which is a mandatory check defined in RFC 7519 (JSON Web Token) and RFC 9068 (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens). The 'aud' claim is intended to restrict the scope of a token to the specific resource server for which it was issued. In the vulnerable configuration, the API treats any valid token signed by the realm's private key as authorized for administrative actions, regardless of the intended target service.\nThe exploitation flow is as follows: 1) An attacker operating a compromised or malicious client within a Keycloak realm intercepts an access token intended for a different service (a 'legitimate' service that is not the Admin API). 2) The attacker submits this token in the 'Authorization: Bearer' header of a request directed at the Keycloak Admin REST API. 3) The Admin API performs signature validation, confirming the token was issued by the trusted realm, but fails to check if the 'aud' claim matches its own identifier. 4) The API accepts the token and grants the attacker the permissions associated with the token's principal, effectively escalating the attacker's privileges to that of an administrator if the original bearer of the token held such rights or if the API configuration defaults to elevated context.\nThe root cause is a deficiency in the token validation middleware of the Admin API component, which treats the JWT signature as the sole criterion for authorization. By neglecting the audience restriction, the system allows for 'token substitution' or 'cross-service relay' attacks. An attacker with a legitimate client identity can essentially bypass intended service boundaries. Post-exploitation, an attacker can manipulate realm configurations, export sensitive secrets, create new administrative accounts, or modify identity provider settings, leading to a complete compromise of the realm's security posture. Because the API does not enforce the intended audience, it creates a lack of 'least privilege' enforcement across the ecosystem of integrated services, allowing a token with limited scope to be elevated to full administrative utility."
}