CVE-2026-18963

Think of Keycloak as the “front door” that manages user logins. Normally, when someone resets a password, they must confirm it by clicking a link in an email. This bug skips that email confirmation, letting an attacker directly push a new password for a victim account—so the attacker can log in as that user.

This matters if you run Red Hat Build of Keycloak (including the Red Hat Single Sign-On 7 setup or the Red Hat JBoss Enterprise Application Platform Expansion Pack component) using the affected Keycloak versions (26.4 / 26.4.15, or 26.6 / 26.6.6). Because the flaw is reachable from the network in default configuration and does not require authentication, exposure is primarily about whether your system’s password reset (“Forgot password”) functionality is accessible.

This is RED because the bug enables account takeover for any user without requiring login, and it is reachable in default configuration. Even if you haven’t seen an incident, attackers can trigger the takeover directly over the network—so you should upgrade immediately.

Confirm whether you’re exposed

1. Determine which product stack you run:
   • Red Hat build of Keycloak, specifically versions in scope: 26.4 (including 26.4.15), or 26.6 (including 26.6.6).
   • Also check if you’re using Red Hat Single Sign-On 7 or the Red Hat JBoss Enterprise Application Platform Expansion Pack with these Keycloak versions.
2. Verify the exact installed build/package versions in your environment (application server / container / installed RPMs) to confirm whether you match the affected Keycloak version lines.

Upgrade to the fixed releases (preferred)

• Red Hat build of Keycloak 26.4 → fixed in 26.4.15-1
• Red Hat build of Keycloak 26.6 → fixed in 26.6.6-1

After upgrading:

• Validate that the “Forgot password” flow still works as expected for legitimate users (but is now protected by the fix).
• Review logs for unexpected password-reset events for any user accounts.

If you can’t upgrade right away (temporary mitigation)

• Disable “Forgot password” across all realms:
  • In the RHBK administration console: Realm settings → Login → Forgot password
• Confirm the change for every realm, since bypassing the email verification protection is tied to the reset-credentials capability.

What to monitor

• Authentication logs and password reset events for:
  • Password reset attempts that did not originate from expected user activity.
  • Sudden login activity from accounts shortly after reset attempts.

CISA KEV / exploitation status

• This CVE is not listed in the CISA KEV feed (per provided findings).
• The findings indicate patches were released for the relevant Keycloak versions, and there is no clear dated public claim of exploitation in the provided news section.

Severity is critical (CVSS 9.1) and the impact is account takeover (C:H, I:H; availability impact not indicated in the provided findings). The weakness is CWE-640 and the core mechanism is an unauthenticated bypass of the password reset flow’s email verification step: an attacker can force a password reset for any user directly, without completing the required email confirmation, resulting in the attacker gaining full control of the victim account.

Attack vector is network-based, with no authentication required and no user interaction required, and the issue is reachable in default configuration (from the findings). KEV is not listed for this CVE in the provided data. Exploitation maturity is not evidenced as “in the wild” in the provided findings (no dated press claim; press section notes no clear dated claim and no exploitation reported), but the presence of a RED verdict indicates this should be treated as actively dangerous in practice. EPSS is provided as a prediction (do not treat it as a confirmation of exploitation).