As reported by The Hacker News, Red Hat and the Keycloak project have patched a critical authentication bypass vulnerability that fundamentally undermines the password reset mechanism in one of the most widely deployed open-source identity and access management platforms. This is not a minor hardening issue — it is a complete collapse of the reset-credentials flow's state machine.
Vulnerability Summary
| Field | Detail |
|---|---|
| CVE | CVE-2026-18963 |
| CVSS | 9.1 (Critical) |
| CWE | CWE-640 — Weak password recovery mechanism |
| Affected Products | Upstream Keycloak (pre-26.7.2); Red Hat Build of Keycloak 26.4.x and 26.6.x |
| Patched Versions | Keycloak 26.7.2; RHBK 26.4.15; RHBK 26.6.6 |
| Exploitation in the Wild | None observed as of August 24, 2026 |
| Authentication Required | No — fully unauthenticated, no user interaction |
| Impact | Complete account takeover of any user, including administrators |
Why This Matters More Than a Typical CVE
Keycloak is rarely just another application in the stack — it is the identity provider sitting in front of dozens or hundreds of downstream services. As security researcher Enzo Mongin observed in related work, once an attacker crosses Keycloak's boundary, they reach everything behind it. An administrative account takeover at the IAM layer is effectively a skeleton key to the entire application ecosystem.
The technical root cause is particularly concerning. The reset-credentials flow is supposed to enforce a strict state transition: initiate reset → verify email via action token → allow password update. The vulnerability allows an attacker to craft a request that transitions the authentication session directly to the password update phase, bypassing the email-verified action token entirely. This is a state machine design failure, not a simple input validation bug — which means defensive detection cannot rely on looking for malformed tokens or unusual parameters alone.
Who Is Most Exposed
The most dangerous aspect is the combination of unauthenticated access and administrative account takeover. An attacker doesn't need credentials, phishing, or social engineering — just network reachability to the reset endpoint.
Shield53 Recommendations — Immediate Actions
- Patch immediately. Upgrade upstream Keycloak to 26.7.2. For RHBK, apply operator bundle 26.4.15-1 or 26.6.6-1 and the corresponding container images (26.4-23 / 26.6-12). Red Hat errata RHSA-2026:56519 through RHSA-2026:56524 cover all package and image variants.
- If patching cannot be completed within hours, consider temporarily disabling self-service password reset for internet-facing realms until the update is applied. This removes the vulnerable endpoint from external attack surface.
- Audit reset-credentials flow logs for anomalous activity — look for password updates that were not preceded by a valid action token verification event. Any such sequence is indicative of exploitation or probing.
- Rotate administrative credentials in any Keycloak deployment that was exposed to the internet and remained unpatched between the disclosure window and remediation. Assume compromise if there is any log gap.
- Review realm administrator assignments post-remediation. An attacker who seized an admin account may have created additional persistent identities or modified flow configurations to maintain access.
- Enforce network-level restrictions on Keycloak admin consoles and sensitive endpoints going forward — WAF rules, IP allowlisting, or reverse proxy authentication layers should supplement application-level controls.
Identity infrastructure vulnerabilities occupy a tier of risk above typical application flaws. When the IAM layer fails, every dependent control — SSO, RBAC, MFA enrollment, session management — fails with it. Treat this patch as non-negotiable and assume your reset endpoint has been probed.
