CVE-2026-118959: Keycloak-services: keycloak-services: required actions bypassed via kc_action parameter
A flaw was found in the required action provider mechanism of Keycloak. The issue occurs when an authorization request includes the kcaction query parameter set to a mandatory action already assigned to the user, such as profile verification or terms and conditions. Due to incorrect handling of application-initiated actions, Keycloak may skip these mandatory challenges and issue an authorization code. This can allow a user to bypass administrative requirements and gain access to the application without completing necessary profile updates or agreeing to terms.
Other sources
A vulnerability was found in Keycloak where mandatory required actions can be bypassed using the kcaction query parameter. When an authorization request includes kcaction set to the alias of a pending mandatory action (such as VERIFYPROFILE or TERMSANDCONDITIONS), the server incorrectly treats the request as an application-initiated action. Because these specific providers do not support application-initiated invocation, they are added to an internal ignored actions list. Consequently, the authentication flow completes without presenting the required challenge to the user. An authenticated attacker with a pending required action can exploit this by appending the kcaction parameter to their authorization request. Successful exploitation allows the attacker to obtain valid access tokens and bypass admin-enforced requirements like profile attribute updates or acceptance of terms and conditions on every login.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs an authenticated Keycloak user account with a mandatory required action still pending. They must be able to submit an authorization request that sets kc_action to the alias of that pending action.
What is the practical impact after a successful bypass?
Keycloak may complete the authentication flow and issue an authorization code without presenting the mandatory challenge. The user can then gain access to the application without completing required profile updates or accepting terms and conditions.
Which types of pending actions are implicated?
The issue applies to mandatory actions whose aliases can be supplied through kc_action and that do not support application-initiated invocation. The reported examples are VERIFY_PROFILE and TERMS_AND_CONDITIONS.