ZeroHour
The Hacker Newspublished ()ingested @TheHackersNews

Critical Keycloak Password Reset Flaw Could Let Unauthenticated Attackers Take Over Any Account

AI summary · glm-5.3-flash

Red Hat patched critical Keycloak flaw CVE-2026-18963 (CVSS 9.1) allowing unauthenticated attackers to take over any account, including administrative ones.

Keycloak and Red Hat patched CVE-2026-18963, a CVSS 9.1 flaw (CWE-640) caused by improper state validation in the reset-credentials flow, letting an unauthenticated remote attacker force a password reset without the emailed action token and achieve full account takeover, including admin accounts. Upstream Keycloak 26.7.2 and Red Hat Build of Keycloak 26.4.15/26.6.6 contain fixes; four RHSA errata were issued August 18, 2026. No evidence of exploitation or public exploits exists as of August 24, 2026; mitigation is disabling the Forgot Password feature in all realms.

  • Unauthenticated takeover of any account, including admins
  • Fixed in Keycloak 26.7.2 and RHBK 26.4.15/26.6.6
  • No exploitation evidence or verified public PoC yet
  • Mitigation: disable Forgot Password across all realms
  • Same release also fixed CVE-2026-15571 account-linking flaw

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-15571
Predictable-hash account-linking forgery in Keycloak enables full account takeover

CVE-2026-15571 is a high-severity (CVSS 7.3) flaw in the legacy client-initiated account-linking endpoint of Keycloak, the widely used open-source identity and access management server, where the mechanism that guards the linking flow is based on a hash that a malicious OIDC client can predict (CWE-341). An attacker who controls an OIDC client registered in the victim's realm tricks the user into authenticating, then forges a valid linking URL that connects the victim's account to an external identity controlled by the attacker. The result is full account takeover: the attacker can subsequently log in as the victim, with high confidentiality and integrity impact per the CVSS vector (no availability impact, and the attack requires low privileges plus user interaction). Any Keycloak deployment using the legacy account-linking endpoint is affected, and the available data does not specify affected or fixed version ranges, so current installations should be assumed vulnerable until patched. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known; EPSS currently estimates only about a 0.3% probability of exploitation within 30 days.

Do: Upgrade Keycloak to a patched release as soon as the Red Hat/Keycloak advisory publishes fixed versions (none specified in the available data), keeping in mind that only realms that use the legacy client-initiated account-linking flow and contain OIDC clients an attacker could control are meaningfully exposed. Until you can patch, restrict which clients may register in your realms, audit existing client registrations for unexpected additions, and review identity-broker account-linking events for links your users did not initiate. Recent coverage of an unauthenticated Keycloak password-reset account-takeover flaw describes a separate issue, so confirm your Keycloak patch level against both advisories.

7.3<1%
  • Red Hat Keycloak
mass≈1M+ end users across tens of thousands of deployments (widely deployed open-source IAM; no public install metric)
CVE-2026-18963
Unauthenticated Account Takeover via Password Reset Flow in Red Hat Build of Keycloak

Red Hat Build of Keycloak contains a critical flaw (CVE-2026-18963) in the reset-credentials flow of the keycloak-services component, the core identity and access management engine (CWE-640, broken password recovery). An unauthenticated attacker with network access to the Keycloak server can trigger the password reset process for any user and bypass the required email verification link, directly setting new credentials for the target. This yields full account takeover of the victim user, including high impact to confidentiality and integrity, with no privileges, user interaction, or special conditions required. Any deployment of Red Hat Build of Keycloak is potentially affected; the affected version ranges are not specified in the available data, so defenders should consult the Red Hat advisory for fixed releases. No public proof of concept, CISA KEV listing, or confirmed in-the-wild exploitation is known yet, though EPSS assigns a 3.2% probability of exploitation within 30 days (87th percentile).

Do: Identify all Red Hat Build of Keycloak deployments in your environment and upgrade to the fixed versions listed in the Red Hat advisory once published (specific fixed versions are not included in the available data). Until patching, restrict network exposure of Keycloak instances, and audit account/credential-change activity for unexpected password resets, since the flaw requires no authentication or user interaction. Monitor for suspicious password-reset email activity reported by users, which may indicate active probing or exploitation.

9.13% PoC
  • Red Hat Build of Keycloak (keycloak-services component, reset-credentials flow)
large≈10,000s of deployments (public internet scans have catalogued tens of thousands of exposed Keycloak instances; RHBK-specific install counts and user totals…
Full article701 words · extracted from thehackernews.com · click to collapse

Swati KhandelwalAug 24, 2026Vulnerability / Identity Security

Red Hat and the Keycloak project have released patches to address a critical security flaw in the open-source identity and access management server that could allow an unauthenticated remote attacker to take over any user account by forcing a password reset.

The vulnerability, assigned the CVE identifier CVE-2026-18963, is rated 9.1 on the CVSS scoring system by Red Hat, which acts as the CVE Numbering Authority (CNA) for the flaw. It has been classified as a weak password recovery mechanism for a forgotten password (CWE-640).

Users of upstream Keycloak are advised to update to version 26.7.2, released August 19, 2026, while customers running Red Hat build of Keycloak (RHBK) should apply the updates shipped for 26.4.15 and 26.6.6.

There is no evidence that the flaw has been exploited, and no verified public exploit has been located as of August 24, 2026.

Red Hat said in its CVE advisory that the root cause is "improper state validation within the reset-credentials authentication flow," the sequence Keycloak runs when a user requests password recovery. The company assessed the severity as Critical because an unauthenticated remote attacker can exploit the flaw without any user interaction.

The defect lies in how the flow's state is managed, according to the Red Hat bug report. An attacker sends a specially crafted request to the reset-credentials endpoint. The authentication session then transitions directly to the password update phase. The action token that Keycloak normally sends via email is never required.

Successful exploitation results in a complete account takeover of any user, "including administrative accounts," by resetting their password.

Escape researcher Enzo Mongin, writing about a separate Keycloak access-control flaw he disclosed in July, said an attacker who crosses one of the server's boundaries does not stop at Keycloak, and that "they get into everything sitting behind it."

Red Hat issued four errata on August 18, 2026 (RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 and RHSA-2026:56524), covering the standalone server packages and the container images for two RHBK streams. The fixed versions are as follows -

  • Red Hat build of Keycloak 26.4 is unaffected from operator bundle 26.4.15-1, and from the rhbk/keycloak-rhel9 and rhbk/keycloak-rhel9-operator images 26.4-23
  • Red Hat build of Keycloak 26.6 is unaffected from operator bundle 26.6.6-1 and from the keycloak-rhel9 and operator containers 26.6-12
  • Upstream Keycloak is fixed in 26.7.2

The GitHub advisory for the flaw lists both the affected and the patched versions as unknown, and the CVE record carries only Red Hat product references.

The initial CVE record listed Red Hat Single Sign-On 7 as unaffected and the Red Hat JBoss Enterprise Application Platform Expansion Pack as affected. A later revision narrowed the product list, and NVD's display truncates it, so the current status of both is not established.

For deployments that cannot be updated immediately, Red Hat has published a temporary mitigation -- turn off the "Forgot password" functionality across all realms. In the RHBK administration console, the setting sits under Realm settings, then Login, then Forgot password. Red Hat said the setting must be applied to every realm and that customers should upgrade to a fixed version as soon as possible.

CVE-2026-18963 was one of eight CVE identifiers listed as fixed in the Keycloak 26.7.2 release notes. The same release addressed CVE-2026-15571, a predictable account-linking hash that enables account takeover through a malicious OpenID Connect (OIDC) client.

Two weeks earlier, on August 5, 2026, Keycloak 26.7.1 shipped fixes for twelve CVEs, including a SAML identity-provider-initiated broker login that bypassed a link-only restriction and a default dynamic client registration policy that allowed role forgery via user property mappers.

Separately, Univention said in a post published August 20 that "Nubus is not affected by this issue" because the forgotten-password feature is not activated in its Keycloak deployments. Red Hat credited James Paremain with reporting the flaw.

No source addresses whether the fix fully resolves the flaw.

Whether every realm with the forgotten-password feature enabled is exploitable, or only certain reset-credentials flow configurations, is not stated by any of the published sources.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Text extracted automatically; images, tables and formatting may be missing. Original: https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html