CVE-2026-97176: Keycloak-services: keycloak-services: essential acr requirement silently bypassed via cookie authenticator
A flaw was found in Keycloak's Level of Authentication (LoA) enforcement within the ConditionalLoaAuthenticator component. When a client requests a specific acr level as essential:true via the OIDC claims request parameter and an existing SSO session is present, Keycloak can silently issue a token asserting a lower acr level than required without triggering the mandatory forced-level failure. The vulnerability exists because when the browser flow re-evaluates an existing session via the Cookie authenticator, LoA-gated Conditional sub-flows may be disabled (e.g., if the user lacks the required credentials for the higher level). In this scenario, the ConditionalLoaAuthenticator fails to register its top-flow-success callback. Consequently, the onTopFlowSuccess() method is never executed, and the mandatory forced-level check is bypassed. An authenticated attacker with a valid low-level session can exploit this to obtain tokens for clients requiring higher authentication levels (essential:true) without providing the necessary additional factors. This results in an authentication level bypass for relying parties that trust the acr claim to guarantee the level was verified during the current authentication.
Other sources
A flaw was found in the Level of Authentication enforcement mechanism of Keycloak, an identity and access management solution. The issue occurs when a client specifically requires a higher security level for a user who already has an active session at a lower level. Due to a logic error in how session re-evaluations are handled, Keycloak may incorrectly issue a token at the lower security level instead of enforcing the required higher level, potentially allowing unauthorized access to sensitive resources that rely on these security claims.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this authentication-level bypass?
Relying parties are exposed if they request a specific ACR level as essential:true and trust the acr claim to confirm that the required authentication level was actually verified. The issue affects flows involving an existing SSO session where LoA-gated conditional sub-flows can be disabled.
What does an attacker need to exploit the issue?
The attacker must already be authenticated with a valid session at a lower authentication level. They can then request tokens for a client requiring a higher essential ACR level without completing the required additional factors.
How can defenders identify potentially affected configurations?
Review clients that use the OIDC claims request parameter to require an ACR level with essential:true. Prioritize configurations where browser cookie-based SSO session reuse occurs and higher-LoA conditional sub-flows may be disabled because users lack the credentials required for that level.