CVE-2026-18963: Keycloak reset-credentials flow: unauthenticated account takeover CWE-640

Keycloak's "reset credentials" (forgot-password) flow can be pivoted by an unauthenticated attacker onto any victim account. Two defects combine: (1) the authenticator-selection ("try another way") state is stored as a plain boolean auth note (AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED="true"), so a simple GET refresh of the reset-credentials execution URL re-renders the selector screen for the current flow execution; and (2) ResetCredentialEmail.action() blindly calls context.success() without verifying that the request actually arrived via the emailed action token (ACTION_TOKEN_USER_ID auth note). An attacker who initiates a password reset for a victim's username can therefore re-enter the selector screen after the reset email was sent to the victim, POST to the now-reachable reset-credential-email execution without any action token, force the flow forward to the UPDATE_PASSWORD required action, and set an attacker-chosen password on the victim account — a full unauthenticated account takeover. The attacker never sees the victim's reset email.

• Package/component: org.keycloak:keycloak-services (services module: org.keycloak.authentication.DefaultAuthenticationFlow, org.keycloak.authentication.authenticators.resetcred.ResetCredentialEmail)
• Affected: Keycloak upstream < 26.4.15, 26.5.x, 26.6.0–26.6.5, 26.7.0–26.7.1 (verified at source level); Red Hat build of Keycloak 26.4/26.6 before container 26.6-12; RH-SSO 7; JBoss EAP Expansion Pack (per advisory RHSA-2026:56519/56523/56524)
• Verified affected: quay.io/keycloak/keycloak:26.7.1 (source tag 26.7.1, commit 73f08b397f193712b26d317210dce99898129709)
• Verified fixed: quay.io/keycloak/keycloak:26.7.2 (source tag 26.7.2, contains backport of fix commit cf6e4c8be318f1e38c4001730fe6db6930dad050)
• Risk: critical (CVSS 9.1). Any unauthenticated remote attacker who knows a victim's username can take over the account (new password + authenticated session), provided the realm has "forgot password" enabled — a default, common configuration.

Impact Parity

• Disclosed/claimed maximum impact: unauthenticated account takeover (authz_bypass).
• Reproduced impact from this run: unauthenticated account takeover — the victim's password was replaced without possessing the reset email link, an authenticated session (authorization code) as the victim was issued, and the new password was verified against the token endpoint (HTTP 200) while the old password stopped working (HTTP 400).
• Parity: full.
• Not demonstrated: nothing material — the claimed impact was fully reproduced.

Root Cause

In the vulnerable code (services/src/main/java/org/keycloak/authentication/DefaultAuthenticationFlow.java, tag 26.7.1):

1. When the user clicks "try another way", processAction() stores AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED = "true" (a boolean), not bound to any execution.
2. processFlow() checks only Boolean.parseBoolean(note) plus a non-null CURRENT_AUTHENTICATION_EXECUTION note. After the attacker posts the victim's username, ResetCredentialEmail.authenticate() sends the reset email and calls context.forkWithSuccessMessage(EMAIL_SENT); the FORK handling sets CURRENT_AUTHENTICATION_EXECUTION to the email execution id. A subsequent GET refresh of the original reset-credentials URL therefore re-renders createSelectAuthenticatorsScreen(emailExecution), whose HTML form action leaks the email execution UUID (execution=<uuid>).
3. ResetCredentialEmail.action() (vulnerable) is:

   public void action(AuthenticationFlowContext context) {
       context.getUser().setEmailVerified(true);
       context.success();
   }
   

   Posting to the leaked email-execution URL (no action token required) invokes this blind success, the required-elements chain continues to reset-password / UPDATE_PASSWORD, and the attacker sets a new password on the victim identity attached to the authentication session by ResetCredentialChooseUser.

Fix (upstream commit cf6e4c8be318f1e38c4001730fe6db6930dad050, PR #51844, backported to 26.4.15 / 26.6.6 / 26.7.2):

• The selector note now stores the execution model id, and processFlow() only re-renders the selector when the note matches CURRENT_AUTHENTICATION_EXECUTION (otherwise the note is removed) — the GET refresh after the email fork no longer re-renders the selector screen.
• ResetCredentialEmail.action() now requires user.getId().equals(authSession.getAuthNote(DefaultActionTokenKey.ACTION_TOKEN_USER_ID)), i.e. success is only possible through the emailed action token; otherwise the flow fails with INVALID_USER.

The upstream regression test ResetPasswordTest.resetPasswordTryAnotherWay() served as the PoC blueprint for the flow-selector re-entry.

Reproduction Steps

1. bundle/repro/reproduction_steps.sh (self-contained; helper bundle/repro/smtp_sink.py is a promoted required artifact).
2. The script:
   • Verifies at source level that tag 26.7.1 lacks and tag 26.7.2 contains the fix hunk.
   • Starts a dependency-free Python SMTP sink container (captures the victim's reset email, proving the action-token link is generated and sent only to the victim).
   • Starts Keycloak 26.7.1 (vulnerable), provisions realm cvetest (resetPasswordAllowed=true, SMTP → sink), user victim (email victim@cvetest.local, password OldPass123!), and a public direct-grant client atk-cli used only for verification.
   • Runs the full browser-equivalent attack with curl (cookie jar, per-page rotating session_code honored): login page → forgot-password → POST tryAnotherWay=on → POST username=victim → GET-refresh the original reset URL → POST the leaked email execution URL → POST the new password.
   • Asserts the pivot: step-5 refresh re-renders kc-select-credential-form, step-6 returns 302 → login-actions/required-action?execution=UPDATE_PASSWORD, step-7 returns 302 → /account/?...&code=... (attacker session as victim), and the token endpoint returns 200 for the new password / 400 for the old one.
   • Repeats the attack twice (password restored between attempts via admin API).
   • Repeats the same procedure twice against Keycloak 26.7.2 (fixed): the refresh must re-render the "You should receive an email shortly" page (no selector) and the victim password must remain unchanged.
   • Writes bundle/repro/runtime_manifest.json on every exit (trap) and streams all output to bundle/logs/reproduction_steps.log.
3. Expected evidence: 2/2 vulnerable attempts EXPLOITED, 2/2 fixed attempts BLOCKED, exit code 0.

Evidence

• bundle/logs/reproduction_steps.log — full transcript of both phases.
• bundle/logs/vuln-attempt-{1,2}.log — per-attempt exploit transcripts. Key excerpts (attempt 1):
  • step5 GET refresh -> selector markers=1 email-sent markers=0 and the re-rendered selector form action now contains execution=0089b76d-... (the email execution, different from the choose-user execution 141b34d5-... used in steps 2–4).
  • step6 POST email execution (no action token) -> HTTP/1.1 302 Found Location: .../login-actions/required-action?execution=UPDATE_PASSWORD... — the blind context.success() fired without any action token.
  • step7 new password -> HTTP/1.1 302 Found Location: http://localhost:8080/realms/cvetest/account/?session_state=...&code=... — the attacker is issued an authorization code as victim.
  • step8 takeover verify: NEW password token HTTP 200, OLD password token HTTP 400.
• bundle/logs/fixed-attempt-{1,2}.log — step5 GET refresh -> selector markers=0 email-sent markers=1; old password still 200, new password 400 → BLOCKED.
• bundle/logs/smtp-capture-final.log — the captured "Reset password" email addressed To: victim@cvetest.local containing the real /realms/cvetest/login-actions/action-token?key=eyJ... link (which the attacker never receives).
• bundle/logs/http/<role>-<n>/step*.html|*.hdr — raw HTTP responses/headers for every step of every attempt.
• bundle/logs/keycloak-vuln.log, bundle/logs/keycloak-fixed.log — server logs; server-version reported by /admin/serverinfo was 26.7.1 / 26.7.2 respectively.
• bundle/repro/runtime_manifest.json — runtime identity (image digests quay.io/keycloak/keycloak@sha256:f1f1f01e… vulnerable, …@sha256:83133051… fixed), attempt results, proof artifact list.
• Environment: rootless Docker 27.5.1 on Linux x86_64; Keycloak start-dev (H2), hostname http://localhost:8080; no sanitizers involved (product runtime proof).

Recommendations / Next Steps

• Upgrade to a fixed build: upstream Keycloak ≥ 26.4.15 / ≥ 26.6.6 / ≥ 26.7.2; Red Hat build of Keycloak 26.6-12 container or later (RHSA-2026:56519, 56523, 56524).
• The upstream fix is the correct approach: bind the selector-screen auth note to the execution model id and require the ACTION_TOKEN_USER_ID note in ResetCredentialEmail.action().
• Regression testing: keep ResetPasswordTest.resetPasswordTryAnotherWay() and add an end-to-end test asserting that a GET refresh after the email fork cannot surface the email execution's action URL.
• Defense-in-depth: consider invalidating or single-using the email execution state once the action token is issued, and rate-limiting reset-credential initiations per username/IP.

Additional Notes

• Idempotency: the script is fully idempotent — it re-creates the docker network and containers, truncates the SMTP capture, and restores the victim's password between attempts. Verified by two consecutive successful runs (exit 0 both times).
• The exploit uses only unauthenticated endpoints; no SMTP access, no victim interaction, and no knowledge beyond the victim's username are required. The victim's email delivery is not even required to succeed for the pivot (Keycloak forks the flow with a success message even when sending fails), but this reproduction proves real email generation via the SMTP capture.
• The fork behavior (forkWithSuccessMessage → cloned tab on the browser flow) is why the legitimate "email sent" page is displayed on a cloned authentication-session tab while the original tab retains the selector note and the email execution as current — the exact state the GET refresh abuses.
• The verification client atk-cli (public, direct grants) exists only to prove the password change; it plays no role in the exploit path itself.