CVE-2026-18963 Keycloak Unauthenticated Account Takeover Explained

CVE-2026-18963 is a critical vulnerability in Keycloak’s password recovery workflow that can allow a remote unauthenticated attacker to take control of another user’s account without possessing the victim’s password and, critically, without completing the email verification step that is supposed to authorize a password reset.

The vulnerability affects the reset-credentials authentication flow implemented by the keycloak-services component. Red Hat assigned the issue a CVSS v3.1 score of 9.1 Critical, with the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

This vector captures why CVE-2026-18963 deserves immediate attention: the attack is remotely reachable, requires low complexity, requires no privileges, and requires no user interaction. Successful exploitation can provide high confidentiality and integrity impact because the attacker can replace the victim’s credentials and subsequently authenticate as that user. (Red Hat Customer Portal)

Red Hat classifies the vulnerability as CWE-640: Weak Password Recovery Mechanism for Forgotten Password. That classification is accurate at the outcome level, but the underlying engineering failure is more interesting than a conventional weak reset-token vulnerability.

The password-reset token itself does not simply have low entropy.

Instead, Keycloak’s authentication state machine can be manipulated in a way that causes the reset process to advance as though the email verification requirement had already been satisfied.

That distinction matters.

CVE-2026-18963 is fundamentally an authentication-flow state validation vulnerability.

Red Hat CVE-2026-18963 advisory

CVE-2026-18963 at a Glance

Property	詳細
CVE	CVE-2026-18963
製品	Keycloak / Red Hat build of Keycloak
コンポーネント	keycloak-services
脆弱性	Reset-credentials authentication-flow bypass
主な影響	Unauthenticated account takeover
CVSS v3.1	9.1 Critical
CWE	CWE-640
Authentication required	いいえ
User interaction required	いいえ
Network reachable	はい
Main security control bypassed	Email verification/action token
Upstream patched release	Keycloak 26.7.2
Patched maintenance branches	26.4.15, 26.6.6
Temporary mitigation	Disable Forgot Password
Public technical PoCs	Yes, now publicly available

Keycloak itself lists CVE-2026-18963 among the security fixes delivered in Keycloak 26.7.2, released on August 19, 2026. (Keycloak)

Keycloak 26.7.2 release notes

Why a Keycloak Account Takeover Is Especially Dangerous

Keycloak is rarely just another web application.

Organizations commonly place it at the center of an identity architecture involving multiple applications, APIs, administrative interfaces, internal systems and sometimes cloud services.

Conceptually, the architecture may look like this:

                    ┌───────────────────┐
                    │     Keycloak      │
                    │ Identity Provider │
                    └─────────┬─────────┘
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
      Customer Portal     Admin Console    Internal Apps
             │                │                │
             ▼                ▼                ▼
           APIs          Infrastructure      Services

An account takeover vulnerability against an ordinary SaaS application compromises one application account.

An account takeover vulnerability against an identity provider can potentially compromise an identity shared across an entire application ecosystem.

The actual blast radius depends on the target user’s privileges, client configurations, realm structure, session policies and applications federated to Keycloak. It should therefore not be assumed that exploiting CVE-2026-18963 automatically grants organization-wide access.

But the architectural position of Keycloak makes that escalation path realistic.

An attacker who resets the credentials of an administrator, privileged employee or service-linked identity could potentially gain access far beyond the Keycloak login page itself.

How Keycloak Password Reset Normally Works

To understand CVE-2026-18963, it helps to understand the security property that the password-reset workflow is intended to enforce.

A simplified reset process looks like this:

User requests password reset
          │
          ▼
User identifies account
          │
          ▼
Keycloak generates email action token
          │
          ▼
Reset email sent to registered mailbox
          │
          ▼
User clicks authenticated reset link
          │
          ▼
Keycloak verifies action token
          │
          ▼
User receives permission to set new password

The security boundary is obvious:

Knowing an account’s username or email address must not be equivalent to controlling that account.

Possession of the registered email account provides the second piece of evidence.

The reset link therefore acts as a capability. Whoever possesses the valid action token is temporarily authorized to move the reset state machine into the credential-update stage.

In abstract terms:

IDENTIFY_ACCOUNT
       │
       ▼
SEND_RESET_EMAIL
       │
       ▼
VERIFY_ACTION_TOKEN
       │
       ▼
UPDATE_PASSWORD

The vulnerable implementation allowed the system to reach the final state without reliably proving that the VERIFY_ACTION_TOKEN state had actually succeeded.

That is the heart of CVE-2026-18963.

The Root Cause of CVE-2026-18963

Red Hat describes the root cause as improper state validation within the reset-credentials authentication flow. (Red Hat Customer Portal)

The upstream Keycloak patch makes the problem more concrete.

The fix modifies several important areas, particularly:

DefaultAuthenticationFlow.java
ResetCredentialEmail.java
ResetPasswordTest.java

According to the upstream patch review, the remediation does three important things:

1. It binds authenticator-selector state to the specific authentication execution.
2. It rejects reset-email actions that do not have the appropriate matching action token.
3. It adds regression testing covering stale reset-flow navigation. (ギットハブ)

This combination is important because the vulnerability was not merely the result of one badly written もし statement.

Two pieces of state management interacted in an unsafe way.

Authentication Selector State Was Too Weakly Bound

Keycloak authentication flows can contain multiple executions.

An authentication session may therefore track concepts such as:

CURRENT_AUTHENTICATION_EXECUTION
AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED

In vulnerable versions, the state recording whether an authentication-method selector had been displayed could behave too much like a general boolean condition rather than a state tied tightly enough to the specific execution for which that selector was rendered.

Conceptually, the vulnerable assumption looked roughly like this:

selectorDisplayed = true

The safer model is closer to:

selectorDisplayedFor = execution_12345

Why does that difference matter?

Because authentication flows are state machines.

A state marker saying:

"the selector has been displayed"

is substantially weaker than:

"the selector has been displayed for this exact authentication execution"

If the first form survives while the flow moves to another execution, stale state can affect an execution for which it was never intended.

The official fix consequently binds selector state to the appropriate execution ID and validates that relationship before trusting it. (ギットハブ)

The Reset Email Execution Also Needed Stronger Validation

The second part of the problem involved ResetCredentialEmail.

A password recovery flow must never equate:

reaching the reset-email authenticator

with:

proving possession of the emailed reset token

Those two statements are fundamentally different.

The patch specifically strengthens this boundary by requiring the reset-email action to have the expected action-token user identity before treating the execution as valid.

The upstream PR summarizes the security change as:

“Rejects reset-email actions lacking a matching action token.”

(ギットハブ)

That is the most important technical sentence in the patch.

The action token is the evidence that connects the browser executing the reset flow to the user who received the reset email.

Without validating that evidence, reaching the action handler can incorrectly become equivalent to authorization.

The Vulnerable State Machine

A useful way to understand CVE-2026-18963 is not as an endpoint vulnerability but as an invalid state transition.

A safe password-reset state machine should enforce:

                 VALID TOKEN
RESET EMAIL ─────────────────────► UPDATE PASSWORD

Anything else should fail:

                 NO TOKEN
RESET EMAIL ─────────X───────────► UPDATE PASSWORD

With CVE-2026-18963, manipulated authentication-flow state could effectively cause the second transition to become reachable.

The security invariant:

UPDATE_PASSWORD requires proof of mailbox ownership

was therefore violated.

That produces the account takeover.

Simplified CVE-2026-18963 Attack Path

At a conceptual level, exploitation can be represented as:

Unauthenticated attacker
        │
        ▼
Starts password recovery flow
        │
        ▼
Manipulates authentication flow state
        │
        ▼
Victim account enters reset workflow
        │
        ▼
Reset email stage becomes current execution
        │
        ▼
Email-token possession check is bypassed
        │
        ▼
Flow reaches password update
        │
        ▼
Attacker chooses new credentials
        │
        ▼
Victim account compromised

Importantly, Red Hat explicitly states that the attacker does ない need the user to interact with the reset email. Successful exploitation can allow the attacker to set new credentials directly. (Red Hat Customer Portal)

That is why the issue is an unauthenticated account takeover rather than simply a password-reset workflow anomaly.

Why CVE-2026-18963 Is Not Just Another Password Reset Bug

Many password-reset vulnerabilities fall into familiar categories:

脆弱性タイプ	Typical failure
Predictable token	Attacker guesses reset token
Token leakage	Reset token appears in logs or URLs
Host-header poisoning	Reset URL points to attacker infrastructure
Token reuse	Used token remains valid
ユーザー列挙	Reset flow reveals whether users exist
Weak recovery questions	Recovery evidence is guessable
CVE-2026-18963	Required verification state can be bypassed

CVE-2026-18963 belongs to a more subtle category.

The reset token itself can be cryptographically sound.

The problem is that the surrounding state machine does not always require the token before allowing the privileged transition.

This illustrates an important security engineering principle:

A strong credential is useless if the application logic contains a route around the point where the credential is checked.

Why MFA May Not Save a Vulnerable Deployment

A common reaction to account takeover vulnerabilities is:

“Our users have MFA, so a password reset alone should not be enough.”

That assumption needs careful examination.

Authentication MFA and account recovery are often separate security workflows.

Imagine the normal login flow:

Password
   +
OTP / WebAuthn
   =
Authentication

But the reset flow may instead be:

Email ownership
      │
      ▼
Reset password

If recovery logic eventually creates an authentication state or resets credentials without enforcing an additional authenticator, login MFA may not provide the protection administrators expect.

Whether MFA prevents complete takeover therefore depends on the exact reset-credentials flow configuration.

Some customized reset flows may require additional authentication steps, which can reduce exploitation impact.

But administrators should not assume that ordinary MFA configuration automatically neutralizes CVE-2026-18963.

The vulnerable password recovery path itself must be patched.

Which Keycloak Versions Are Affected?

Public advisory data identifies the following vulnerable release ranges:

Release branch	脆弱	Fixed
Keycloak 26.0.x–26.4.x	Before 26.4.15	26.4.15
Keycloak 26.5.x–26.6.x	Before 26.6.6	26.6.6
Keycloak 26.7.x	26.7.0–26.7.1	26.7.2
Current upstream	Older vulnerable builds	Upgrade to a fixed/current release

GitLab’s advisory database describes the affected Maven ranges as starting at 26.0.0 and ending before the respective patched maintenance releases. (advisories.gitlab.io)

The Keycloak project’s CVE issue also carries release labels for 26.4.15, 26.6.6, 26.7.2 and 26.8.0, confirming the branches receiving the correction. (ギットハブ)

For upstream deployments following the current Keycloak line, 26.7.2 is the important minimum patched release from the August security update.

Administrators should nevertheless move to the latest supported Keycloak release appropriate for their environment rather than treating 26.7.2 as a permanent target.

How to Check Your Installed Keycloak Version

On a conventional Keycloak deployment, check the running version rather than relying only on documentation or deployment manifests.

例えば、こうだ：

bin/kc.sh --version

Containerized environments should also inspect the image actually running:

kubectl get pods -n keycloak

Then inspect the container image:

kubectl get pod <keycloak-pod> -n keycloak \
  -o jsonpath='{.spec.containers[*].image}'

For Docker:

docker ps --format '{{.Image}} {{.Names}}'

Do not assume that updating a Helm values file means the cluster has successfully rolled over to the patched image.

Verify the deployed workload.

This matters particularly in environments where:

Desired image: 26.7.2
Running image: 26.7.1

can persist because of failed rollouts, image caching, pinned digests or operator configuration.

Red Hat Build of Keycloak

Organizations using Red Hat Build of Keycloak should use the Red Hat errata associated with the CVE instead of blindly applying community-version assumptions.

Red Hat’s security data identifies multiple advisories for CVE-2026-18963, including:

RHSA-2026:56519
RHSA-2026:56520
RHSA-2026:56523
RHSA-2026:56524

and identifies corrected RHBK builds associated with the affected supported branches. (Red Hat Customer Portal)

This distinction matters because enterprise distributions frequently backport security fixes rather than simply mirroring upstream release numbers.

The Official Keycloak Patch

The upstream repair was merged through Keycloak pull request #51844.

Keycloak CVE-2026-18963 fix PR #51844

The PR explicitly states that it closes CVE-2026-18963 and hardens the reset-credentials flow. It was merged into the Keycloak main branch on August 20, 2026. (ギットハブ)

The patch changes the security model in two complementary ways.

Before

Authentication flow state could be trusted too broadly:

selector state exists
        │
        ▼
assume relevant execution can use it

The reset-email stage could also be reached without sufficiently proving the action-token relationship.

After

Keycloak requires stronger relationships:

selector execution ID
        │
        ├── must match ──► current execution ID
        │
        ▼
continue

and:

action token identity
        │
        ├── must match ──► reset user identity
        │
        ▼
allow reset flow

This is classic defense in depth.

The first correction prevents stale authentication-selector state from being reused incorrectly.

The second prevents the sensitive email-reset authenticator from succeeding merely because execution control reaches it.

Why the Patch Is Better Than Simply Blocking One Attack Sequence

An inferior patch might attempt to recognize the specific known request sequence and block it.

例えば、こうだ：

if request looks like published exploit:
    deny

That would be fragile.

The actual Keycloak fix strengthens the security invariants of the authentication state machine.

The system now asks:

Does this selector state belong to this execution?

and:

Does the reset action possess the identity evidence expected from the action token?

That approach protects against broader classes of state confusion rather than one literal proof-of-concept request sequence.

Can CVE-2026-18963 Be Exploited Remotely?

Yes.

The CVSS vector contains:

AV:N

meaning Network Attack Vector.

It also contains:

PR:N

meaning no privileges are required, and:

UI:N

meaning the victim does not need to interact with the attack.

Combined with:

AC:L

for low attack complexity, these characteristics explain the 9.1 rating. (Red Hat Customer Portal)

From a defender’s prioritization perspective, this means CVE-2026-18963 should rank considerably higher than vulnerabilities requiring:

local access
+
existing credentials
+
victim interaction
+
complex race conditions

The attacker-facing prerequisites are unusually favorable.

Public Exploit Availability Changes the Risk Calculation

At the time of some early reporting on August 24, 2026, researchers noted that they had not yet found a verified public exploit. (ハッカーニュース)

That statement is no longer useful as a current operational assumption.

Public GitHub repositories now contain CVE-2026-18963 proof-of-concept implementations and vulnerable test labs. (ギットハブ)

This changes the patching equation.

Once technical exploitation details become publicly reproducible, the defender’s window between disclosure and commodity exploitation can shrink dramatically.

Organizations should therefore not delay remediation simply because they have not observed an incident.

Is CVE-2026-18963 Being Exploited in the Wild?

As of August 31, 2026, the sources reviewed for this article do not provide reliable evidence of widespread confirmed exploitation in the wild, and a search of CISA’s published KEV material did not surface CVE-2026-18963.

That should not be interpreted as evidence that exploitation has not occurred.

There are several reasons.

First, public PoCs now exist.

Second, password-reset exploitation can resemble legitimate account recovery activity.

Third, Keycloak event logging may be disabled or retained only for a limited period.

Fourth, an attacker who successfully changes a user’s credentials may subsequently interact with downstream applications through apparently valid authenticated sessions.

Detection therefore requires more than searching for a single obvious exploit signature.

Detecting Possible CVE-2026-18963 Exploitation

Defenders should think about detection in three layers:

Layer 1: HTTP / reverse proxy activity
Layer 2: Keycloak authentication events
Layer 3: Credential and account state changes

No single layer is guaranteed to be complete.

Layer 1: Reverse Proxy and Ingress Logs

Inspect requests associated with Keycloak reset-credentials and login-action workflows.

The objective is not simply to detect someone using “Forgot Password.” That is expected behavior.

Instead, investigators should correlate unusually compressed sequences of:

reset workflow requests
        │
        ▼
credential update

where there is no corresponding request representing the legitimate action-token navigation expected after the victim clicks the reset email.

A legitimate recovery should usually contain evidence corresponding to:

reset request
    ↓
email delivery
    ↓
action-token navigation
    ↓
password update

A suspicious pattern is:

reset request
    ↓
password update

without expected token-consumption activity

Public incident-response research around the vulnerability specifically recommends looking for the absence of the expected /login-actions/action-token navigation between reset initiation and credential update. (ギットハブ)

That is useful as a heuristic, not as absolute proof.

Keycloak Event Analysis

A community-developed defensive hunt for CVE-2026-18963 recommends correlating password-reset and credential-update events with earlier reset-email events. (ギットハブ)

Useful event categories may include activity resembling:

SEND_RESET_PASSWORD
RESET_PASSWORD
UPDATE_PASSWORD
UPDATE_CREDENTIAL

Investigators should ask:

Was a password changed?
        │
        ▼
Was there a legitimate recovery request?
        │
        ▼
Was the action-token stage observed?
        │
        ▼
Do source IPs and timestamps make sense?

One particularly useful hunting strategy is identifying password changes that cannot be reconciled with:

• legitimate user recovery;
• administrator-driven credential resets;
• enrollment flows;
• approved helpdesk actions.

A credential change by itself does not prove compromise.

Context matters.

Database-Level Hunting

Where incident response requires historical investigation, the Keycloak database can provide evidence even if application event retention is incomplete.

A public defensive project designed specifically around CVE-2026-18963 notes that credential.created_date can help identify credentials created during the exposure window, even where event logging was disabled. (ギットハブ)

That is valuable because event histories may expire.

A high-level investigative query should identify:

user
credential type
credential creation/change time
realm

for the period between:

date vulnerable version introduced
          ↓
date patched version deployed

Each result should then be correlated against known business activity.

Do not automatically classify every credential update as compromise.

Build an Exposure Window

This vulnerability is particularly well suited to timeline-based incident response.

For each Keycloak environment, determine:

T0 = first deployment of an affected release
T1 = CVE disclosure / increased public awareness
T2 = public exploitation details available
T3 = patched release deployed

The investigation window should usually begin at T0, not merely the disclosure date.

A vulnerability can be exploited before public disclosure.

Public disclosure only changes attacker awareness; it does not create the vulnerable code.

Indicators That Deserve Investigation

Potential warning signs include:

信号	なぜそれが重要なのか
Unexpected password changes	Direct result of the attack
Admin password reset with no ticket	High-impact identity compromise
Password reset followed by unfamiliar IP login	Possible takeover
Reset flow immediately followed by credential update	Abnormally compressed workflow
Missing action-token navigation	Consistent with bypassed email verification
New downstream sessions after password reset	Possible post-compromise activity
Offline token activity	Persistence may survive password remediation
Privileged actions shortly after reset	Possible attacker objective

None of these indicators individually proves CVE-2026-18963 exploitation.

Their value comes from correlation.

What to Do If You Suspect Account Takeover

Patching the server stops new exploitation of the vulnerable path.

It does ない undo an account compromise that already occurred.

If suspicious credential changes are discovered, responders should treat the event as an identity compromise.

The response process should include:

Disable or contain affected identity
        │
        ▼
Reset credentials through trusted channel
        │
        ▼
Revoke active sessions
        │
        ▼
Invalidate offline sessions/tokens
        │
        ▼
Review connected applications
        │
        ▼
Rotate accessible secrets if necessary
        │
        ▼
Investigate post-reset activity

The public Keycloak incident-hunting project similarly recommends revoking sessions and offline tokens and then investigating downstream actions performed by the affected account. (ギットハブ)

This is especially important for administrator identities.

An attacker may use the compromised Keycloak identity simply as the initial access mechanism.

The actual objective may be elsewhere.

Temporary Mitigation: Disable Forgot Password

Red Hat provides a clear temporary mitigation:

Disable the Forgot Password functionality across all realms.

(Red Hat Customer Portal)

This prevents access to the vulnerable recovery path.

For organizations unable to upgrade immediately, this is materially better than leaving the vulnerable reset flow exposed.

However, it should be treated as an emergency control rather than a replacement for patching.

Reasons include:

1. Users lose self-service password recovery.
2. Every relevant realm must actually be covered.
3. Configuration could later be re-enabled.
4. The vulnerable code remains present.
5. Operational procedures may unintentionally restore exposure.

The permanent solution is to run a patched version.

Recommended Remediation Priority

For Internet-exposed Keycloak systems with password recovery enabled, CVE-2026-18963 should generally be treated as an emergency identity-security patch.

A practical priority model is:

Environment	優先順位
Internet-facing Keycloak + Forgot Password enabled	Emergency
Admin accounts reachable through vulnerable realm	Emergency
Keycloak federating many production apps	Emergency
Internal-only Keycloak with broad employee access	非常に高い
Forgot Password disabled	High — mitigation exists, still patch
Patched version already verified	Monitor and investigate exposure window

The distinction between mitigated そして patched is important.

A mitigated server can become vulnerable again if configuration changes.

A patched server has the underlying security defect corrected.

Verification After Patching

Do not stop at:

deployment pipeline succeeded

Verify the security outcome.

A robust validation process includes:

1. Verify running Keycloak version
2. Verify every replica/pod
3. Check old instances are terminated
4. Confirm rollback images are patched
5. Confirm Forgot Password configuration
6. Validate legitimate reset still works
7. Confirm invalid reset state cannot reach password update
8. Review logs from the historical exposure window

Testing should occur against systems you own or are explicitly authorized to assess.

For production systems, prefer non-destructive validation that confirms the vulnerable state transition is unavailable without actually changing another user’s credentials.

Why Version-Only Vulnerability Scanning Is Not Enough

Some vulnerability scanners detect CVE-2026-18963 primarily through Keycloak version information.

For example, Tenable describes its check as relying on the application’s reported version rather than exploiting the issue. (Tenable®)

That approach is safe and useful for inventory.

But version scanning answers:

Is this build expected to contain the vulnerability?

It does not necessarily answer:

Is this specific reset flow exploitable?

or:

Was it exploited last week?

Security teams should separate these questions.

Exposure detection

Asset inventory
+
version detection
+
realm configuration

Vulnerability validation

Authentication-flow behavior
+
safe security testing

Incident investigation

Keycloak events
+
database history
+
reverse-proxy logs
+
downstream application activity

These are three different tasks.

Security Testing Lessons From CVE-2026-18963

CVE-2026-18963 also demonstrates why identity systems require business-logic testing rather than only conventional endpoint scanning.

A traditional scanner may ask:

Does this parameter contain SQL injection?
Does this page contain XSS?
Is this package vulnerable?

Those questions remain important.

But this vulnerability requires another class of reasoning:

Can authentication state from execution A
incorrectly authorize execution B?

That is a state-machine question.

The interesting test cases include:

resume flow
restart flow
switch authentication method
revisit old execution
reuse authentication session
submit stale forms
move backward in flow
move forward without expected proof

For identity infrastructure, those transitions are often where high-impact vulnerabilities hide.

Authentication Flows Should Be Tested as Graphs

Instead of viewing authentication as a list of pages:

Page 1
Page 2
Page 3

security engineers should model it as a graph:

                 ┌──► OTP ──────┐
                 │               │
IDENTIFY ─► AUTH ┼──► WebAuthn ─┼──► SUCCESS
                 │               │
                 └──► Password ──┘

Password recovery creates another graph:

                EMAIL TOKEN
                    │
IDENTIFY ─► EMAIL ──┼──► UPDATE PASSWORD
                    │
                    X
              no proof allowed

Then test not only the legitimate edges, but unintended ones.

例えば、こうだ：

Can EMAIL be reached twice?

Can stale browser state select another execution?

Can the user return to an earlier step?

Can an execution be invoked directly?

Does every sensitive authenticator independently validate its proof?

Can state from one branch affect another branch?

CVE-2026-18963 is a textbook example of why this methodology works.

The Deeper Engineering Lesson

Authentication systems frequently accumulate state in multiple places:

cookies
HTTP parameters
authentication sessions
server-side notes
action tokens
execution IDs
browser tabs
required actions
realm configuration

Security problems emerge when two components have different assumptions about which piece of state is authoritative.

Component A may believe:

current execution proves where the user came from

while component B assumes:

if this action method is running,
the token must already have been checked

Neither assumption is safe unless the relationship is explicitly validated.

Security-sensitive transitions should therefore follow a principle similar to:

Never infer proof from control flow
when the proof itself can be verified.

If a token proves mailbox possession, verify the token.

If an execution ID proves flow ownership, verify the execution ID.

Do not infer either property merely because the request reached the right handler.

Why Identity Vulnerabilities Can Have Disproportionate Blast Radius

Consider a company using Keycloak for:

Git platform
CI/CD platform
internal dashboard
customer console
cloud administration
VPN portal
monitoring
developer tools

A single identity might authenticate to several of those systems.

The vulnerability itself remains an account takeover.

But downstream impact becomes:

Keycloak account takeover
        │
        ├──► application access
        ├──► API access
        ├──► administrative privileges
        ├──► sensitive data
        └──► lateral movement

This is why identity-provider vulnerabilities should often receive remediation priority above an equivalent CVSS vulnerability in an isolated application.

The identity system is part of the organization’s security control plane.

Defender Checklist for CVE-2026-18963

アクション	ゴール
Inventory all Keycloak environments	Establish exposure
Determine running versions	Identify vulnerable deployments
Identify all realms	Avoid missing secondary realms
Determine whether Forgot Password is enabled	Confirm attack surface
Upgrade to patched releases	Remove root cause
Temporarily disable Forgot Password if necessary	Emergency mitigation
Review historical password changes	Hunt for takeover
Correlate reset and action-token events	Identify bypass patterns
Review reverse-proxy logs	Reconstruct HTTP activity
Investigate privileged accounts first	Reduce blast radius
Revoke suspicious sessions	Remove attacker persistence
Review downstream applications	Find post-compromise activity
Improve event retention	Support future incident response

Frequently Asked Questions

What is CVE-2026-18963?

CVE-2026-18963 is a critical vulnerability in Keycloak’s reset-credentials flow that can allow an unauthenticated remote attacker to bypass the email-verification step of password recovery and potentially set new credentials for another account. Red Hat rates it Critical with CVSS 9.1. (Red Hat Customer Portal)

What is the main impact?

The primary impact is unauthenticated account takeover.

An attacker does not need the victim’s existing password and does not need the victim to click the password-reset email.

Does the attacker need access to the victim’s email?

No.

Bypassing the requirement to prove access to the reset email is precisely what makes the vulnerability dangerous.

Does CVE-2026-18963 require authentication?

No.

The CVSS vector specifies PR:N.

Does the victim need to click anything?

No.

The vulnerability has UI:N.

Is CVE-2026-18963 Critical?

Yes.

Red Hat assigned CVSS v3.1 9.1 Critical. (Red Hat Customer Portal)

What CWE is CVE-2026-18963?

CWE-640, Weak Password Recovery Mechanism for Forgotten Password.

What Keycloak version fixes CVE-2026-18963?

For the current upstream line, Keycloak 26.7.2 contains the security fix. Patched maintenance releases also include 26.4.15 そして 26.6.6 for the corresponding branches. (Keycloak)

Can I mitigate the vulnerability without immediately upgrading?

Yes.

Red Hat recommends disabling Forgot Password across all realms if immediate upgrading is impossible. (Red Hat Customer Portal)

That should be considered temporary mitigation rather than a permanent solution.

Does MFA completely stop CVE-2026-18963?

Not necessarily.

MFA protection depends on the structure of the reset-credentials flow. Normal login MFA does not automatically guarantee that password recovery requires the same authenticators.

Patch the vulnerable Keycloak version regardless.

Are public exploits available?

Yes.

Public technical implementations and test environments for CVE-2026-18963 are now available, increasing the urgency of remediation. (ギットハブ)

Is CVE-2026-18963 actively exploited?

As of August 31, 2026, reliable public confirmation of widespread active exploitation was not identified in the sources reviewed for this article.

However, public proof-of-concept material exists, so absence of confirmed exploitation should not be used to justify delaying remediation.

結論

CVE-2026-18963 is dangerous not because Keycloak generated a weak reset token, but because the authentication state machine could be manipulated into bypassing the security boundary that the token was supposed to enforce.

That distinction makes the vulnerability an important case study in modern identity security.

The vulnerable logic effectively allowed this invariant:

Password reset requires verified mailbox ownership

to become:

Password reset may succeed
because authentication-flow state says
the process has advanced far enough

The Keycloak patch fixes that trust problem by binding selector state to the correct authentication execution and requiring the reset-email action to possess matching action-token identity evidence. (ギットハブ)

For defenders, the response is straightforward: identify every Keycloak deployment, verify the running version rather than the intended version, upgrade vulnerable instances, temporarily disable Forgot Password where patching cannot happen immediately, and investigate historical credential changes across the exposure window.

For security engineers, CVE-2026-18963 offers a broader lesson.

Authentication flows should not only be tested for whether the correct path works.

They should be tested for whether an attacker can reach a privileged state through an incorrect path.

In identity infrastructure, that difference can be the difference between a harmless workflow bug and a complete account takeover.