CVE-2026-18963: Keycloak Unauthenticated Account Takeover via Forced Password Reset — Detection and Remediation Guide

Red Hat and the Keycloak project have released patches for CVE-2026-18963, a critical vulnerability in the open-source Keycloak identity and access management (IAM) server that carries a CVSS score of 9.1. The flaw allows an unauthenticated, remote attacker to take over any user account by abusing the password reset flow — no credentials, no prior foothold, no user interaction required beyond the attacker's request.

If you run Keycloak — whether as a standalone identity broker, an OIDC/SAML federation layer, or embedded in Red Hat Single Sign-On (RH-SSO) downstream products — this is a stop-what-you're-doing event. Keycloak typically sits in front of your most sensitive applications: admin portals, developer tooling, VPN gateways, Kubernetes dashboards, and internal SaaS. An attacker who can force-reset any account's password can impersonate realm administrators, application superusers, and service owners. In practical terms, this is a skeleton key for every application that trusts your Keycloak realm.

Having led IR engagements where identity providers were the initial target, I can tell you plainly: IdP compromise is among the worst-case scenarios in modern environments because every downstream session token, federation trust, and SSO-integrated app inherits the blast radius. Treat this with the same urgency you gave the critical IAM flaws of years past.

Technical Analysis

Affected Products

• Keycloak (open-source upstream) — vulnerable versions prior to the patched releases published by the Keycloak project
• Red Hat build of Keycloak / Red Hat Single Sign-On (RH-SSO) — Red Hat is acting as the CNA and has published its own advisory and patched builds

Organizations running Keycloak containers (Quarkus distribution), Helm-deployed instances on Kubernetes, or legacy WildFly-based RH-SSO are all potentially in scope. Confirm your exact version against the Red Hat advisory (linked in Remediation below) — do not assume a managed or containerized deployment is safe by default.

Vulnerability Profile

How the Attack Works (Defender's View)

Based on the disclosure, the flaw resides in Keycloak's password reset / account recovery logic. The attack chain, from a defender's perspective:

1. The attacker sends crafted, unauthenticated requests to the Keycloak authentication endpoints responsible for initiating or processing password resets (the reset-credentials required action flow, exposed under the realm's /realms/{realm}/login-actions/ and /realms/{realm}/protocol/openid-connect/ paths depending on configuration).
2. Due to the logic flaw, the attacker can force a password reset on an arbitrary account — effectively bypassing the verification controls (such as possession of the victim's email) that normally gate the recovery flow.
3. The attacker completes the reset, sets a new password, and authenticates as the victim — including realm administrators if targeted.

The critical defensive observation: exploitation traffic looks like legitimate password-reset traffic. There is no malformed payload signature to catch on the wire in the traditional sense. Detection therefore hinges on behavioral anomalies in reset flow usage: spikes in reset requests, resets for privileged accounts, resets followed by immediate logins from unfamiliar source IPs, and resets originating from sources that have no business touching your IdP (Tor exits, hosting/VPN ASNs, foreign geographies inconsistent with your workforce).

Exploitation Status

At the time of this writing, the vulnerability has been disclosed alongside vendor patches from Red Hat and the Keycloak project. Given the severity (CVSS 9.1), the unauthenticated nature, and the fact that Keycloak is internet-facing by design in most deployments, defenders should operate under the assumption that weaponization will follow quickly once technical details circulate. Identity-provider flaws of this class historically see rapid reverse-engineering of patches into working exploits. Do not wait for confirmed in-the-wild exploitation to patch — patch first, then hunt retrospectively using the detections below.

Detection & Response

This is a technical threat, and the good news is that Keycloak generates rich, high-fidelity telemetry — if you've enabled it. Keycloak's event logging (realm events: RESET_PASSWORD, UPDATE_PASSWORD, LOGIN, and associated error events) is your primary detection surface, supplemented by reverse proxy / ingress access logs. If you have not enabled event listeners (eventsListener: jboss-logging and email), do so now — you'll need this data for both detection and forensics.

Sigma Rules

These rules target the behavioral patterns of forced-reset abuse observed at the web/proxy layer and in Keycloak event logs forwarded via Syslog/JSON. Tune realm names and source allowlists to your environment.

---
title: Keycloak Mass Password Reset Requests From Single Source
id: 3f8c2a71-6b4e-4d9a-b1c7-9e2f5a8d0c31
status: experimental
description: Detects a high volume of password reset flow initiations against Keycloak realms from a single source, consistent with CVE-2026-18963 forced-reset account takeover attempts.
references:
  - https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1078
logsource:
  category: webserver
  product: keycloak
detection:
  selection:
    cs-uri-query|contains:
      - '/realms/'
      - 'reset-credentials'
      - 'forgot-password'
  condition: selection
falsepositives:
  - Legitimate user self-service password resets (low volume per source)
  - Load balancer health checks hitting realm endpoints
level: high
---
title: Keycloak Password Reset Followed by Login From Suspicious Source
id: 8a1d4e62-2c7f-4b53-9d8a-4f1c6b3e7a92
status: experimental
description: Detects Keycloak account recovery and password update events targeting administrator or privileged accounts, a key indicator of CVE-2026-18963 exploitation leading to account takeover.
references:
  - https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.persistence
  - attack.t1098
  - attack.t1078
logsource:
  product: keycloak
  service: events
detection:
  selection_event:
    keycloak_event_type|contains:
      - 'RESET_PASSWORD'
      - 'UPDATE_PASSWORD'
      - 'SEND_RESET_PASSWORD'
  selection_target:
    keycloak_username|contains:
      - 'admin'
      - 'root'
      - 'administrator'
      - 'superuser'
  condition: all of selection_*
falsepositives:
  - Scheduled admin password rotation by IAM team
  - Helpdesk-initiated resets (correlate with ticket system)
level: critical

Analyst note: The second rule will fire rarely in well-run environments — and when it does, it matters. Baseline your legitimate admin reset cadence. If your org never resets the master realm admin via the web flow, any such event is a page-worthy alert.

KQL — Microsoft Sentinel / Defender

Keycloak access and event logs ingested into Sentinel via Syslog, CEF, or a custom JSON connector can be hunted with the following queries. The first hunts reset-flow anomalies at the proxy/ingress layer; the second correlates reset events with subsequent logins from new sources.

// Hunt 1: Spike in password reset endpoint hits per source IP (proxy/ingress logs via CommonSecurityLog)
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where RequestURL has_any ("reset-credentials", "forgot-password", "login-actions")
    and RequestURL has "/realms/"
| summarize ResetAttempts = count(), DistinctTargets = dcount(DestinationUserName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, RequestURL
| where ResetAttempts > 10 or DistinctTargets > 3
| sort by ResetAttempts desc

// Hunt 2: Password reset event followed by successful login from a previously unseen source IP (Keycloak events via Syslog)
let Lookback = 7d;
let Resets = Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("RESET_PASSWORD", "UPDATE_PASSWORD", "SEND_RESET_PASSWORD")
| extend User = extract(@"userId[=\"']?([^\"',\s}]+)", 1, SyslogMessage),
         ResetIP = extract(@"ipAddress[=\"']?([0-9a-fA-F:\.]+)", 1, SyslogMessage)
| project ResetTime = TimeGenerated, User, ResetIP;
let KnownIPs = Syslog
| where TimeGenerated > ago(Lookback)
| where SyslogMessage has "LOGIN"
| extend IP = extract(@"ipAddress[=\"']?([0-9a-fA-F:\.]+)", 1, SyslogMessage)
| distinct IP;
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has "LOGIN" and SyslogMessage !has "LOGIN_ERROR"
| extend User = extract(@"userId[=\"']?([^\"',\s}]+)", 1, SyslogMessage),
         LoginIP = extract(@"ipAddress[=\"']?([0-9a-fA-F:\.]+)", 1, SyslogMessage)
| join kind=inner Resets on User
| where abs((TimeGenerated - ResetTime) / 1m) < 30
| where LoginIP !in (KnownIPs) or LoginIP == ResetIP
| project ResetTime, User, ResetIP, LoginTime = TimeGenerated, LoginIP
| sort by ResetTime desc

If Hunt 2 returns results where ResetIP and LoginIP match an external hosting provider or VPN ASN, escalate to IR immediately — that is the classic exploitation signature.

Velociraptor VQL

For Keycloak servers under your management, use Velociraptor to collect the server's own log artifacts and identify reset/update events plus the active network connections to the Keycloak process — useful for scoping an incident where patching happened late.

-- Collect Keycloak credential-reset indicators from server logs and live connections
LET logs = SELECT FullPath, parse_line_with_regex(
        line=Line,
        regex="(?P<Time>^[0-9T:\-\.]+).*(?P<Event>RESET_PASSWORD|UPDATE_PASSWORD|SEND_RESET_PASSWORD|LOGIN).*?(?P<IP>ipAddress[=\"']?[0-9a-fA-F:\.]+)?") AS Parsed
    FROM foreach(
        row={ SELECT FullPath FROM glob(globs=[
            '/opt/keycloak/data/log/*.log',
            '/var/log/keycloak/*.log',
            '/opt/rh-sso*/standalone/log/*.log'
        ]) },
        query={ SELECT FullPath, Line FROM parse_lines(filename=FullPath) }
    )
    WHERE Line =~ 'RESET_PASSWORD|UPDATE_PASSWORD|SEND_RESET_PASSWORD'

SELECT FullPath, Parsed.Time AS EventTime, Parsed.Event AS EventType, Parsed.IP AS SourceIP
FROM logs

UNION ALL

SELECT '' AS FullPath, '' AS EventTime, 'ACTIVE_CONNECTION' AS EventType,
       format(format='%v:%v', args=[Raddr.IP, Raddr.Port]) AS SourceIP
FROM netstat()
WHERE Name =~ 'java'
   OR Laddr.Port in (8080, 8443)

Remediation / Verification Script

Use the following Bash script on Keycloak hosts to inventory the running version, confirm whether the patched build is deployed, verify event logging is enabled (critical for detection), and temporarily restrict reset flow exposure if patching must be deferred.

#!/bin/bash
# CVE-2026-18963 Keycloak verification & hardening script
# Run on Keycloak hosts or against container images. Requires root for config inspection.

echo "=== [1] Identify running Keycloak version ==="
if command -v docker &>/dev/null; then
  docker ps --format '{{.Names}} {{.Image}}' | grep -i keycloak
fi
if command -v kubectl &>/dev/null; then
  kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.containers[*].image}{"\n"}{end}' 2>/dev/null | grep -i keycloak
fi
# Bare-metal / systemd installs
ls -d /opt/keycloak* /opt/rh-sso* 2>/dev/null
grep -ri "version" /opt/keycloak/lib/quarkus/build-system.properties 2>/dev/null | head -5

echo "=== [2] Verify event logging is enabled (required for detection/forensics) ==="
grep -ri "eventsListener\|events-listeners\|spi-events-listener" \
  /opt/keycloak/conf/ /opt/rh-sso*/standalone/configuration/ 2>/dev/null
echo "Confirm realm-level 'Save Events' is ON for LOGIN and ADMIN events in the Admin Console."

echo "=== [3] Check for recent forced-reset indicators in logs ==="
for f in /opt/keycloak/data/log/*.log /var/log/keycloak/*.log; do
  [ -f "$f" ] || continue
  echo "--- $f ---"
  grep -E "RESET_PASSWORD|UPDATE_PASSWORD|SEND_RESET_PASSWORD" "$f" | tail -50
done

echo "=== [4] TEMPORARY MITIGATION (only if patching is deferred): block reset flow at proxy ==="
echo "Add to your reverse proxy / ingress BEFORE the Keycloak upstream:"
cat <<'EOF'
# nginx example — blocks unauthenticated access to reset flow until patched
location ~* /realms/[^/]+/login-actions/reset-credentials {
    return 403;
}
EOF
echo "NOTE: This breaks legitimate self-service resets. Patch ASAP and remove."

echo "=== [5] Post-patch: force session invalidation ==="
echo "After upgrading, revoke all sessions: Admin Console > Realm > Sessions > Revoke all,"
echo "and require password change-on-next-login for privileged accounts."

Remediation

1. Patch immediately. Upgrade Keycloak and Red Hat build of Keycloak / RH-SSO to the fixed releases published with the vendor advisories:
   • Red Hat Security Advisory (CNA for CVE-2026-18963): https://access.redhat.com/security/cve/CVE-2026-18963
   • Keycloak project security advisories: https://github.com/keycloak/keycloak/security/advisories
   • Verify the exact fixed version for your distribution stream (upstream Quarkus distribution vs. Red Hat build) — do not assume a minor-version bump is sufficient without checking the advisory's fixed-in list.
2. Assume exposure; hunt retrospectively. Because exploitation is unauthenticated and blends with legitimate traffic, pull reset-flow logs going back at least 30 days (or your retention limit). Look for: reset events for accounts that never requested them, resets for admin/privileged accounts, resets from external or anomalous source IPs, and reset→login pairs from the same or new IPs within a short window.
3. Revoke sessions and rotate credentials after patching. Invalidate all active realm sessions, force re-authentication, and require password resets (legitimately, this time) for any account showing suspicious reset activity — starting with realm admins. Rotate client secrets for any confidential clients if an admin account was potentially compromised.
4. Reduce attack surface. If internet-facing self-service recovery is not a business requirement, disable the "Forgot password" / reset-credentials flow at the realm level (Authentication → Required Actions / Realm Settings → Login) or restrict it at the reverse proxy to internal networks.
5. Enable and centralize event logging. Ensure Keycloak login and admin events are saved, and ship them to your SIEM. Without this telemetry, you cannot scope compromise of your identity plane — full stop.
6. Harden privileged access. Enforce phishing-resistant MFA (WebAuthn/passkeys) on all realm administrator accounts. Even with a forced password reset, MFA adds a meaningful barrier to full session establishment.
7. Review downstream trust. If you find evidence of exploitation, treat every application federated through the affected realm as potentially compromised: review OAuth/OIDC client registrations for rogue additions, check for newly created users or service accounts, and audit role/scope grants made during the exposure window.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub