A single crafted HTTP request. No phishing email. No malware download. No user interaction. Just a login page and a "Forgot Password" link -- and an attacker owns your account.
On August 18, 2026, Red Hat disclosed CVE-2026-18963, a critical vulnerability in Keycloak's password reset flow that earns a 9.1 CVSS score. The flaw lets any unauthenticated attacker hijack any user account -- including administrator accounts -- by skipping the email verification step entirely. Two HTTP requests. That is all it takes.
If your organization runs Keycloak for single sign-on, identity federation, or centralized authentication, this is the vulnerability that should be at the top of your patching queue today.
What Keycloak Actually Does (And Why This Matters)
Keycloak is one of the most widely deployed open-source identity and access management (IAM) platforms in the world. It sits at the front door of enterprise applications, handling authentication for everything from internal dashboards to customer-facing portals. Governments, universities, fintech companies, and SaaS providers all rely on it to manage who gets in and who stays out.
When Keycloak is compromised, the blast radius is not a single application. It is every application behind it. As security researcher Enzo Mongin put it: once an attacker crosses Keycloak's boundary, "they get into everything sitting behind it."
That is what makes CVE-2026-18963 so dangerous. It does not target a niche feature or an obscure configuration. It targets the password reset flow -- the exact mechanism users rely on when they forget their credentials.
How The Attack Works
The vulnerability lives in the reset-credentials authentication flow inside Keycloak's keycloak-services component. This is the sequence that runs when a user clicks "Forgot Password" and requests a reset link.
Normally, the process works like this:
- User requests a password reset
- Keycloak sends a verification email with a unique action token
- User clicks the link, validating the token
- Keycloak allows the user to set a new password
CVE-2026-18963 breaks step 3 entirely. By sending a specially crafted request to the reset-credentials endpoint, an attacker can force the authentication session to transition directly to the password update phase. The server believes the email verification step was completed -- even though no email was ever sent, no token was ever issued, and no link was ever clicked.
According to the French IAM firm Aduneo, which first identified the flaw, the entire attack requires just two HTTP requests. The attacker needs only two things: a valid username and access to the Keycloak login interface. No special privileges. No prior access. No social engineering.
The result is complete account takeover. The attacker sets a new password for the target account and logs in as that user -- including administrators.
The Scope Is Massive
Keycloak is embedded in enterprise infrastructure across every sector. It is the default IAM layer for Red Hat OpenShift, JBoss Enterprise Application Platform, and thousands of custom deployments worldwide.
The vulnerability affects every Keycloak deployment that has the "Forgot Password" feature enabled -- which is the default configuration. That means:
- Enterprise SSO environments where Keycloak manages authentication for dozens of internal tools
- Customer identity platforms where Keycloak handles consumer login flows
- Government and education deployments using Keycloak for federated identity
- DevOps and CI/CD pipelines where Keycloak gates access to infrastructure
Red Hat rated the flaw as Critical because exploitation requires zero authentication, zero user interaction, and can be performed remotely. The only prerequisites are knowing a target username and having network access to the login page.
Patch Now, Or Disable The Feature
The Keycloak project released patches on August 19, 2026. The fixed versions are:
- Keycloak 26.7.2 (upstream)
- Keycloak 26.6.6 (maintenance branch)
- Keycloak 26.4.15 (long-term support branch)
Red Hat also shipped errata for the Red Hat Build of Keycloak (RHBK) covering container images and operator bundles for both the 26.4 and 26.6 streams.
If patching is not immediately possible, Red Hat recommends a temporary mitigation: disable the "Forgot Password" feature across all realms. In the administration console, navigate to Realm Settings > Login and toggle off "Forgot password." This must be applied to every realm individually.
The tradeoff is clear -- users lose self-service password reset -- but it closes the attack vector until a proper patch can be deployed.
What To Check Right Now
At the time of disclosure, no public exploitation has been confirmed. But that window is closing fast. The Swiss security firm KYOS has already published an exploit trace hunting script on GitHub that queries Keycloak databases for signs of compromise:
- Password changes made during the exposure window (via
credential.created_date) - Successful resets completed without a prior email being sent within 24 hours
- Resets performed through the admin API outside normal patterns
- Event logging status (attackers may disable logging to cover tracks)
If your Keycloak instance has been internet-facing since before August 19, running this audit is not optional. It is essential.
Also worth noting: the same Keycloak 26.7.2 release patched CVE-2026-15571, a separate flaw involving predictable account-linking hashes that could enable account takeover through a malicious OpenID Connect client. If you are patching for CVE-2026-18963, you are picking up this fix as well.
The Bigger Picture: Identity Is The New Perimeter
CVE-2026-18963 is a reminder that identity infrastructure is now the highest-value target in enterprise security. Attackers do not need to breach your network when they can walk through the front door with a valid password.
For organizations in the GCC and MENA region, where digital transformation is accelerating and IAM platforms like Keycloak are increasingly deployed to manage authentication across cloud and on-premise environments, the stakes are especially high. A single compromised identity provider does not just expose one application -- it exposes the entire trust chain.
The fix is available. The mitigation is straightforward. The only question is how fast your team can move.