Two HTTP Requests Are All It Takes to Hijack Any Keycloak Account, Including the Admin's

Start with the number that should worry anyone running self-managed identity infrastructure: two. That's how many HTTP requests it takes to fully hijack a Keycloak account, according to the French identity-and-access-management firm Aduneo, which discovered the flaw. No password guessing, no phishing, no session theft — just two crafted requests against a server that's doing exactly what a password-reset flow is supposed to do, just without checking a step it was supposed to check. Red Hat, which maintains Keycloak and acts as the CVE Numbering Authority for the flaw, assigned it CVE-2026-18963 and rated it 9.1 on the CVSS scale. The root cause, in Red Hat's own words, is "improper state validation within the reset-credentials authentication flow" — the sequence Keycloak runs whenever a user requests a password reset. Under normal operation, that flow requires the user to click a link in a verification email before they're allowed to set a new password. The bug lets an attacker skip straight past that check. An attacker who already knows or can enumerate a target username initiates the reset flow, then manipulates the request sequence to jump directly to the password-set step — never touching the victim's inbox, never needing the victim to click anything at all. Once the new password is set, the account belongs to the attacker, and Keycloak's own audit trail shows nothing more alarming than a successful password update. That last detail is what makes this specific bug worth understanding in depth rather than just patching and moving on: it's classified under CWE-640, weak password recovery mechanism, and the exploitation surface is Keycloak's account console and REST endpoints — reachable over the network, unauthenticated, with no user interaction required at all. That combination is about as close to worst-case as an authentication bypass gets. And because Keycloak is the identity layer behind single sign-on, OAuth flows, and application authentication for a huge number of organizations that would never build their own IAM system from scratch, a compromised Keycloak instance isn't really "one account taken over" — it's a foothold into every application that trusts that Keycloak server's word about who's who. Enzo Mongin, a researcher at the exposure-management firm Escape who disclosed a separate Keycloak access-control flaw back in July, put the underlying risk plainly: an attacker who crosses one of the server's boundaries doesn't stop at Keycloak, they get into everything sitting behind it. Red Hat moved fast once the flaw was reported. Four separate errata went out on August 18 — RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523, and RHSA-2026:56524 — covering both the standalone server packages and the container images across two Red Hat build of Keycloak (RHBK) release streams. Upstream Keycloak got its fix a day later: version 26.7.2, released August 19, which also folds in fixes for four additional CVEs (2026-15571, 2026-17048, 2026-15945, and 2026-14613) plus several dependency-level vulnerabilities, so this is worth treating as a genuine upgrade cycle, not a single-CVE hotfix. If you're running Red Hat build of Keycloak specifically, the patched lines are 26.4 from operator bundle 26.4.15-1 onward, and 26.6 from operator bundle 26.6.6-1 onward. Anything earlier in either branch should be treated as vulnerable. As of this writing there's no evidence of active exploitation and no verified public proof-of-concept in circulation — genuinely good news, and worth taking at face value rather than assuming the worst by default. But "no known exploit yet" is doing a lot of work in that sentence for a bug this simple to weaponize. Aduneo's own assessment was that the attack is straightforward enough to script and automate once someone works out the exact request sequence, and a nine-day-old disclosure with public technical writeups already circulating is not a long runway before that happens. If you run self-managed Keycloak or RHBK anywhere in your environment, the practical move today is threefold: patch to 26.7.2 (or the equivalent RHBK errata) without waiting for a routine maintenance window, and in the meantime, hunt your Keycloak audit logs for the specific pattern this bug leaves behind — a successful UPDATE_PASSWORD event that isn't preceded by a matching VERIFY_EMAIL or EXECUTE_ACTION_TOKEN event for the same user session. That gap is the fingerprint of exactly this exploit, and it's detectable today even before you've finished rolling out the patch. There's a broader thread worth naming here, because it's the same one running through nearly every major story this month. Entra ID, GitLab, DGFiP's tax authority, and now Keycloak — four completely unrelated platforms, four completely different vendors, and in every single case the actual failure sits in the authentication or access layer rather than in some exotic corner of the application. None of these needed a novel attack technique. They needed an attacker patient enough to understand exactly how a legitimate flow — password reset, GraphQL API access, stolen-but-valid credentials — was supposed to work, and precise enough to find the one step in that flow that wasn't being checked the way everyone assumed it was. If your organization's security review process still treats "authentication" as a solved problem you configure once and move on from, this month's pattern is a direct argument against that assumption. The flows you built to make security easier for legitimate users are exactly the flows worth re-auditing first.