The Password-Reset Link Was Never Opened. The Account Was Still Taken Over.
A password-reset email is meant to be the point where an identity system proves that the person changing a credential controls the account. A critical Keycloak flaw allowed an unauthenticated attacker to bypass that step and set a new password for another user directly.
The vulnerability is tracked as CVE-2026-18963. Red Hat rates it critical and says successful exploitation can give an attacker full control of any target account without user interaction. Upstream Keycloak fixed the issue in version 26.7.2. Red Hat issued corrected builds for its supported product lines, including 26.4.15 and 26.6.6.
This is not a weakness in email delivery or a trick that persuades a victim to click a link. It is a failure in the server-side state machine that decides whether the password-recovery process has completed its required steps. The reset flow could be forced forward even though the email-verification stage had not established control of the account.
Update, 26 August 2026: CERT-FR now says it is aware of a public proof of concept for CVE-2026-18963. A public repository includes a safe exposure check, an end-to-end exploit path and a self-contained lab that compares vulnerable Keycloak 26.7.1 with patched 26.7.2. This materially lowers the effort required to validate and weaponise the flaw.
Public PoC availability is not the same as confirmed malicious exploitation. Neither Keycloak, Red Hat nor CERT-FR has reported attacks in the wild. Operators should treat the code release as an urgency change and a source of detection detail, not as proof that a compromise occurred.
Public code shortens the path to takeover
The published lab reproduces the failure without opening the victim’s email. Its safe-check mode stops before changing an account and can distinguish the vulnerable state from the patched flow. The full attack needs a target username or email address, a realm with Forgot password enabled, and the built-in reset-email authenticator in the bound recovery flow. A standard enabled public client provides the browser flow needed by the demonstration.
The technical analysis describes two state-validation failures working together. A “Try another way” action leaves an authenticator-selection state attached to the authentication session, while the reset-email execution can accept an action without proving that a valid email action token resumed the flow. Chaining the two moves the session from the parked email step to the password form.
Version guidance needs care. Upstream community Keycloak fixed the current release train in 26.7.2. The 26.4.15 and 26.6.6 numbers are Red Hat vendor backports and should not be treated as interchangeable tags for every community image. Administrators should verify the distribution and running build, not only the apparent minor release.
The link was never opened
A secure recovery process has to bind several events together. The request must identify an account, the server must create a short-lived recovery state, the user must prove control of the registered channel, and only then should the server accept a replacement credential.
Red Hat says the Keycloak flaw was caused by improper state validation in the reset-credentials authentication flow. An attacker could start the recovery process for a chosen user and force it past the email-verification requirement. The attacker could then reach the credential-setting stage and install a password of their choice.
The operational result is unusually direct: a remote unauthenticated party can take over an account without knowing the existing password, possessing the email inbox, or waiting for the user to act. The password-reset link can remain unread while the account changes hands.
That makes the issue more serious than a conventional recovery-link leak. It attacks the authority of the identity provider itself. Applications connected to the affected Keycloak realm may correctly accept the resulting session because the new credential was issued through the legitimate identity system.
One identity failure can reach many applications
Keycloak is commonly deployed as a central identity and access-management service for web applications, internal portals, APIs, and mobile services. It supports standards such as OpenID Connect and SAML and can broker authentication across multiple applications and external identity providers.
That concentration is useful for administrators, but it also changes the blast radius of an account takeover. A compromised local application account may expose one service. A compromised Keycloak account can potentially unlock every relying application that trusts the same identity, subject to the user’s roles and the controls configured around those applications.
The highest-risk targets are administrators, realm managers, service operators, developers, finance users, and other accounts whose federated identity carries privileged roles. An ordinary user’s account can still expose personal data, business records, support systems, or application-specific actions. The exact impact depends on the permissions assigned after authentication, not only on the Keycloak server itself.
Organisations should also account for secondary effects. An attacker who gains a valid account may be able to enroll another authenticator, create application tokens, change recovery information, approve workflows, or use the trusted identity to move into connected systems. Resetting the password again may not invalidate every artefact created during the compromise.
Upgrade paths and an emergency control
Upstream Keycloak included the correction in 26.7.2, released on 19 August 2026. Red Hat’s advisories cover its own supported builds and container images. Administrators should follow the version guidance for the distribution they actually operate rather than treating the upstream number as interchangeable with every vendor package.
Red Hat provides a temporary mitigation when an immediate upgrade is not possible: disable the Forgot password function in every realm. In the administration console, open Realm settings, choose Login, and turn Forgot password off. This removes the vulnerable recovery path but also creates a support and availability tradeoff for legitimate users.
The setting must be applied across all realms. Protecting only the primary realm can leave test, partner, regional, or legacy realms exposed. Teams should inventory every reachable Keycloak deployment, including development environments that share identities or network access with production systems.
Before upgrading, Red Hat recommends backing up the installation, application configuration, databases, and database settings. That is normal change-control advice, but the criticality of the issue argues for an accelerated maintenance window and focused testing rather than a routine future release cycle.
The same release fixed seven additional CVEs
Keycloak 26.7.2 was a multi-CVE security release. The password-reset takeover is the most urgent item because unauthenticated exploit code is public, but it was not the only boundary failure. The release also corrected delegated-administration leaks, a second account-takeover path, a vault-secret disclosure and three dependency issues.
| Vulnerability | Impact and prerequisites | Fixed releases | Workaround and exploitation status |
|---|---|---|---|
| CVE-2026-14613 | FGAP v2 can let a delegated administrator who may view a role enumerate groups assigned to it, including groups the administrator is not authorised to see. | 26.6.6, 26.7.2 and 26.8.0 | No separate vendor workaround was published. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-15571 | A malicious OIDC client can predict the hash protecting the legacy client-initiated account-linking flow. User authentication to the attacker-controlled client is required, after which the attacker can link the victim to an external identity and take over the account. | 26.6.6, 26.7.2 and 26.8.0 | No separate vendor workaround was published. Remove untrusted clients while upgrading. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-15945 | With FGAP v2 enabled, a delegated administrator who can see a child group can expose details of a hidden parent through group search with full representations. | 26.6.7, 26.7.2 and 26.8.0 | No separate vendor workaround was published. Restrict delegated administration until patched. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-17048 | An administrator with realm-management:view-clients can retrieve the plaintext value of a vault-backed rotated client secret through the Admin REST API. The primary client secret is not affected. |
26.6.6, 26.7.2 and 26.8.0 | No separate vendor workaround was published. Limit view-clients and rotate exposed client credentials after patching. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-18963 | An unauthenticated attacker who knows a username or email address can bypass email verification in the built-in reset flow and set a new password. Forgot password and the affected reset-email authenticator must be enabled. | Upstream 26.7.2 and 26.8.0; Red Hat backports 26.4.15 and 26.6.6 | Disable Forgot password in every realm if patching is delayed. CERT-FR confirms public PoC availability. No confirmed malicious exploitation has been reported. |
| CVE-2026-45292 | The bundled OpenTelemetry Java SDK can allocate memory without a bound while processing W3C baggage propagation, creating a denial-of-service condition when the affected telemetry path receives crafted input. | OpenTelemetry API 1.62.0; Keycloak 26.4.15, 26.6.6, 26.7.2 and 26.8.0 | No separate Keycloak workaround was published. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-59888 | Jackson databind can expose an ignored Java Record component when a property-naming strategy renames it, potentially bypassing an intended @JsonIgnore boundary in affected serialization configurations. |
Jackson databind 2.21.4; Keycloak ships 2.21.5 in 26.6.6, 26.7.2 and 26.8.0 | No separate Keycloak workaround was published. No confirmed exploitation or public PoC was identified in this review. |
| CVE-2026-59889 | Jackson databind can write an @JsonUnwrapped property under a less-privileged active @JsonView, potentially disclosing data that the selected view should hide. |
Jackson databind 2.21.5; Keycloak 26.6.6, 26.7.2 and 26.8.0 | No separate Keycloak workaround was published. No confirmed exploitation or public PoC was identified in this review. |
The fixed-version labels come from Keycloak’s issue tracker and release notes. Downstream distributions can carry backports under different package or container tags, so operators should follow the advisory for the product they actually deploy.
What defenders should examine
Patching closes the vulnerable flow. It does not establish whether someone used it before the update. Keycloak operators should review recovery and authentication telemetry for unexplained password changes, recovery requests followed by successful logins from unfamiliar infrastructure, and privileged accounts whose credentials changed without a matching help-desk record.
The public exploit analysis provides more specific hunting pivots. A bypass can show a POST to login-actions/reset-credentials containing tryAnotherWay, followed by another POST to the reset path and a password update without the preceding GET /login-actions/action-token that represents the victim opening the email link. An emailVerified change without a matching verification event is supporting evidence. These patterns are heuristic and should be correlated with reverse-proxy, Keycloak and downstream application logs.
KYOS also published a read-only PostgreSQL hunt script that checks password-credential creation, reset events and the absence of the expected email step. Empty results are not proof of safety when event logging was disabled or retention has expired.
Investigators should correlate identity events with downstream application logs. A suspicious reset may be followed by new sessions, token issuance, role changes, authenticator enrollment, administrative console activity, or access to applications that had not previously been used by the account.
Where compromise is plausible, response should extend beyond another password reset. Revoke active sessions and refresh tokens, remove newly enrolled credentials, inspect changes to account attributes and roles, and review actions performed in connected applications. Administrators should consider whether service-account credentials, API keys, or secrets were reachable through the stolen identity.
Additional controls can reduce the damage of future recovery failures. Require phishing-resistant multifactor authentication for privileged roles, restrict access to the administration console, separate highly privileged identities from daily user accounts, and alert on recovery events involving sensitive users. Recovery should be monitored as an authentication event with security significance, not merely as a customer-support function.
The security boundary is the sequence
The most important lesson from CVE-2026-18963 is that every screen in a recovery journey is not automatically a security control. The control exists only when the server proves that the required states occurred in the correct order and remain bound to the same user, browser context, and short-lived recovery transaction.
Email verification, multifactor prompts, administrator approval, and credential replacement are separate transitions. If the server accepts the final transition without verifying the earlier ones, the visible workflow can look secure while the underlying authorization decision is already broken.
For organisations that use Keycloak as a shared authentication plane, this flaw deserves identity-incident urgency. Patch the supported build, disable recovery temporarily if the update cannot be deployed, hunt for unexplained reset activity, and treat any confirmed takeover as a federated compromise with consequences beyond the login page.
Sources
- Red Hat Product Security: CVE-2026-18963. The page provides no publication date or time.
- Red Hat Security Advisory RHSA-2026:56520, issued 18 August 2026. No publication time is provided.
- Keycloak 26.7.2 release announcement, published 19 August 2026. No publication time is provided.
- CERT-FR advisory CERTFR-2026-AVI-1078, published 25 August 2026. No publication time is provided.
- Snizi, CVE-2026-18963 public exploit, safe check and lab. GitHub does not expose an original publication time on the repository page.
- KYOS, CVE-2026-18963 PostgreSQL hunt script. GitHub does not expose an original publication time on the repository page.
