What changed
Keycloak 26.7.2, released August 19, 2026, fixed CVE-2026-18963 in the reset-credentials flow. Red Hat says improper state validation allowed an unauthenticated remote attacker to complete password recovery without the required email-verification link and directly set new credentials for a target user. Red Hat rates the vulnerability Critical with CVSS 9.1 (network-accessible, low complexity, no privileges and no user interaction). Red Hat Build of Keycloak fixes were shipped for supported 26.4 and 26.6 lines, including 26.4.15 and 26.6.6. If an immediate upgrade is impossible, Red Hat recommends disabling the Forgot Password feature in every realm. Public exploit/PoC material appeared shortly after disclosure; at least one independent security vendor says it observed exploitation attempts in honeypot telemetry, although the CVE is not currently listed in CISA’s Known Exploited Vulnerabilities catalog.
Why it matters
Keycloak often sits in front of multiple applications, APIs and administrative systems, so compromising one identity account can have a much larger blast radius than exploiting a feature inside a single app. The vulnerable path also uses a normal account-recovery feature that many deployments expose publicly. Teams should therefore treat this as an identity-plane patch rather than wait for application-specific indicators. Because proof-of-concept tooling is public, internet-facing deployments have a stronger reason to patch quickly and review logs or account state from the exposure window.
The flaw turns password recovery into an unauthenticated account-takeover path
The reset flow is supposed to require the user to follow a verification link delivered by email before new credentials are accepted. Red Hat says improper state validation allowed an attacker to bypass that requirement and drive the reset process directly, with no existing login or victim click required.
The correct fix is an upgrade, not a WAF rule
Keycloak shipped the upstream fix in 26.7.2, while Red Hat published patched builds for supported product lines. The vendor’s fallback mitigation is operationally blunt but clear: disable Forgot Password across all realms until the deployment can be upgraded.
Public exploitability has increased since the initial disclosure
Initial independent reporting on August 24 said there was no evidence of exploitation and no verified public exploit at that point. Public PoC and scanner material appeared quickly afterward. A security vendor, Previdian, says its honeypots observed exploitation attempts beginning August 25; that claim is independent telemetry rather than a Red Hat or CISA confirmation of compromised production systems.
Identity-server compromise can cross application boundaries
Keycloak often provides authentication for many services. An attacker who resets a privileged or broadly authorized account can inherit whatever access that identity already has, so incident review should consider connected applications and administrative roles rather than only the Keycloak host.
The same release contains several other security fixes
Keycloak 26.7.2 also lists fine-grained admin permission bypasses, secret disclosure and a separate predictable account-linking flaw capable of account takeover. Teams that are behind on the 26.7 line therefore gain more than one security fix by upgrading.