A critical vulnerability in Keycloak could allow an unauthenticated remote attacker to take control of arbitrary user accounts through the platform’s password recovery functionality.
Tracked as CVE-2026-18963, the flaw affects the keycloak-services component and enables an attacker to bypass protections within the reset-credentials workflow. Successful exploitation can allow an attacker to set a new password for a targeted account without knowing the existing credentials or controlling the victim’s email account.
The issue is rated Critical with a CVSS v3.1 score of 9.1. Exploitation can be performed remotely, requires no authentication or user interaction, and can result in a complete loss of confidentiality and integrity for the affected account.
Technical Analysis
Keycloak’s password recovery process normally requires a user to receive an email containing an action token. Access to that token demonstrates control of the email address associated with the account before Keycloak permits the user to choose new credentials.
CVE-2026-18963 breaks this trust boundary.
The underlying weakness involves the way authentication flow state is maintained and validated during the reset-credentials workflow. Analysis of the upstream Keycloak patch shows that selector state could previously persist without being sufficiently tied to the authentication execution that created it. At the same time, the reset credential email action could reach a successful state without adequately verifying that the request contained an action token associated with the targeted user.
Together, these conditions allow an attacker to manipulate the reset flow so that the email-verification stage is effectively bypassed and execution continues to the password update stage.
The Keycloak remediation makes two important changes:
- authentication selector state is now tied to the specific execution identifier that generated it;
- reset-email actions are rejected unless a valid action-token user identity is present.
The patch also introduced regression testing specifically designed to prevent stale reset-flow navigation from recreating the vulnerable condition.
This is significant because the flaw does not merely expose password-reset information or permit denial of service. It breaks the authentication control designed to prove account ownership, allowing the attacker to replace legitimate credentials entirely.
Why the Vulnerability Is Critical
Keycloak is commonly deployed as a centralized identity and access management platform providing authentication and single sign-on to multiple applications.
Compromise of a Keycloak account may therefore have consequences beyond the Keycloak server itself.
A successful attack against a privileged user could potentially provide access to applications federated through the identity provider, administrative functionality, sensitive internal systems, or cloud and enterprise services connected through SSO.
Administrator accounts are particularly high-value targets. Because CVE-2026-18963 requires neither prior authentication nor victim interaction, exposure of the vulnerable reset workflow to the internet materially increases risk.
Affected and Fixed Versions
Upstream Keycloak remediation has been associated with the following fixed release lines:
| Release Stream | Fixed Version |
| Keycloak 26.4.x | 26.4.15 |
| Keycloak 26.6.x | 26.6.6 |
| Keycloak 26.7.x | 26.7.2 |
| Keycloak 26.8.x | 26.8.0 |
Keycloak’s CVE tracking issue explicitly associates the vulnerability remediation with releases 26.4.15, 26.6.6, 26.7.2, and 26.8.0.
For Red Hat build of Keycloak, Red Hat released security updates for both the 26.4 and 26.6 branches.
For the 26.4 stream, fixed builds include:
- Red Hat build of Keycloak 26.4.15
- rhbk/keycloak-operator-bundle 26.4.15-1
- relevant Keycloak and operator container packages at 26.4-23
For the 26.6 stream, fixed builds include:
- Red Hat build of Keycloak 26.6.6
- rhbk/keycloak-operator-bundle 26.6.6-1
- relevant Keycloak and operator container packages at 26.6-12
Red Hat published corresponding critical security advisories for standalone and OpenShift deployments on August 18.
Organizations using older or unsupported Keycloak branches should not assume they are protected simply because their exact build does not appear in a vendor table. Systems should be moved to a supported release containing the fix.
Exploitation and Threat Intelligence
CVE-2026-18963 was publicly disclosed on August 18, 2026.
CISA’s initial SSVC assessment on August 20 recorded exploitation as none, while simultaneously classifying exploitation as automatable and its potential technical impact as total.
Public proof-of-concept repositories began appearing shortly after disclosure, and on August 25, an exploitation-intelligence provider reported observing traffic matching attempts to exploit CVE-2026-18963. Its telemetry recorded 32 attempts from one source IP against one sensor during a roughly 30-minute period.
Mitigation and Remediation
Organizations should upgrade vulnerable installations to a patched Keycloak release as soon as possible.
Red Hat specifically recommends upgrading to a fixed version. Where immediate patching is operationally impossible, administrators can temporarily disable the vulnerable password-recovery functionality.
Within the Red Hat build of Keycloak administration console:
Realm settings → Login → Forgot password → Off
The setting must be disabled across all realms where the functionality is enabled.
This workaround removes the vulnerable self-service password recovery path but should be treated only as a temporary measure because users will no longer be able to perform normal password resets.
Organizations should also determine how long vulnerable Keycloak deployments were exposed and preserve relevant authentication, reverse-proxy, database, and application logs before retention periods remove potentially useful evidence.
If suspected exploitation is identified, incident responders should:
- disable or securely reset the affected account;
- revoke active sessions and offline tokens;
- rotate credentials, API keys, or secrets accessible to the compromised identity;
- investigate activity performed after the suspicious credential change;
- review downstream applications authenticated through Keycloak;
- examine other accounts for similar reset activity.
Stay Safe. Stay Secure.
OP Innovate Research Team
