A flaw was found in the reset-credentials flow of the keycloak-services component

CVE-2026-18963 is a logic flaw in the reset-credentials authentication flow inside the keycloak-services component — the core engine of Keycloak / Red Hat Build of Keycloak (RHBK). An unauthenticated, remote attacker can bypass the email verification step of the password recovery process entirely due to improper state validation. The attacker can force the password reset for any user — including realm admins — and directly set new credentials without the victim ever clicking a link. Affected versions include all Keycloak releases prior to 26.7.2 (upstream), RHBK prior to 26.4-23, and RHBK prior to 26.6-12. Red Hat Single Sign-On 7 is confirmed not affected.

The vendor CVSS of 9.1 CRITICAL is accurate and, if anything, conservative for environments where Keycloak is the sole identity provider. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) correctly reflects that this requires zero authentication, zero user interaction, and delivers high confidentiality and integrity impact. The only reason it isn't a 9.8 is Scope:Unchanged and no Availability impact. For an identity provider — a component whose entire purpose is to gate access to every downstream application — an unauthenticated account takeover is a domain-class event. Red Hat themselves stated no viable mitigation exists. The vendor severity matches reality.

Why this verdict

• Unauthenticated remote attack with zero complexity. The CVSS vector is AV:N/AC:L/PR:N/UI:N — the most dangerous attacker profile. No credentials, no social engineering, no race conditions. Any network-reachable Keycloak instance is exploitable.
• Role multiplier: Keycloak IS the identity provider. This is not a bug in software that *sometimes* runs on an IdP — it IS the IdP. Compromising a realm admin account grants control over every OIDC/SAML client, every user, every federated application. The blast radius is identity-scale → fleet-scale. Per the high-value-role catalog, the verdict floor is CRITICAL.
• Large internet-facing attack surface. Shodan reports 85,000+ exposed Keycloak instances globally. Even internal-only deployments are reachable from any post-initial-access position, and the attack requires only HTTP access to the login page — no admin console needed.
• No vendor-recommended mitigation exists. Red Hat explicitly states that no mitigation meets their deployment criteria. The only remediation is patching. This eliminates the compensating-control safety net that might otherwise buy time.
• EPSS is unreliable at this stage. The CVE is 2 days old. The 0.00391 score reflects data lag, not low risk. Logic bugs in authentication flows are historically weaponized within days of disclosure.

Why not higher?

The CVSS is already 9.1. The only reason it is not 9.8+ is Scope:Unchanged and no Availability impact. The reassessed score stays at 9.1 because the vendor assessment is accurate — the scope boundary is technically correct (Keycloak itself is the vulnerable component), even though real-world blast radius through federation is effectively unbounded.

Why not lower?

Every friction-based downgrade argument fails here. The attack is unauthenticated (no 'requires prior compromise' discount). The attack surface is internet-facing on 85,000+ hosts (no 'limited exposure' discount). The affected component is the identity provider itself (the role-multiplier floor is CRITICAL). No compensating control exists per the vendor. There is no version-range narrowing — all versions before the patch are affected.

1. Deploy WAF rules blocking reset-credentials flow — If you cannot patch within 3 days per noisgate mitigation SLA, place a WAF or reverse proxy rule that returns 403 on all requests to /realms/*/login-actions/reset-credentials*. This breaks legitimate password reset for all users but eliminates the attack surface entirely. Coordinate with your helpdesk to handle password resets manually via admin console until the patch is applied.
2. Enable required MFA (TOTP/WebAuthn) on all accounts, especially admins — While MFA does not protect the password-reset flow itself, it adds a second factor at login time. An attacker who resets credentials still cannot authenticate without the second factor. Deploy within 3 days. Note: this is defense-in-depth, not a complete mitigation — the password is still changed and the user is still disrupted.
3. Restrict network access to Keycloak endpoints — Move Keycloak behind a VPN, zero-trust proxy, or firewall that limits inbound access to trusted networks only. Internet-exposed instances are the highest-risk targets. Deploy within 3 days.
4. Enable and alert on Keycloak event logs — Configure Keycloak to emit events for SEND_RESET_PASSWORD, UPDATE_PASSWORD, and LOGIN to your SIEM. Create a correlation rule that fires when UPDATE_PASSWORD occurs without a corresponding email verification event, or when a password reset is followed by login from a new IP. This enables detection but not prevention.

Run this script on any host with curl and network access to the target Keycloak instance. Invoke as: bash check_cve_2026_18963.sh https://keycloak.example.com. No special privileges required — it only checks the Keycloak server version via the public info endpoint.

#!/usr/bin/env bash
# check_cve_2026_18963.sh — Check Keycloak version for CVE-2026-18963
# Usage: bash check_cve_2026_18963.sh <KEYCLOAK_BASE_URL>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

if [[ $# -lt 1 ]]; then
  echo "Usage: $0 <KEYCLOAK_BASE_URL>"
  echo "Example: $0 https://keycloak.example.com"
  exit 2
fi

BASE_URL="${1%/}"

# Try the serverinfo endpoint (requires no auth on older versions)
# or the well-known endpoint which may leak version
VERSION=""

# Method 1: /auth/admin/serverinfo or /admin/serverinfo (may require auth)
# Method 2: Check the HTML login page for version metadata
# Method 3: Check /realms/master/.well-known/openid-configuration for version hints

# Most reliable: fetch the login page and parse the version from the page source
LOGIN_PAGE=$(curl -sk --max-time 10 "${BASE_URL}/realms/master/account/" 2>/dev/null || true)

if [[ -z "$LOGIN_PAGE" ]]; then
  # Try with /auth prefix (older deployments)
  LOGIN_PAGE=$(curl -sk --max-time 10 "${BASE_URL}/auth/realms/master/account/" 2>/dev/null || true)
fi

if [[ -z "$LOGIN_PAGE" ]]; then
  echo "UNKNOWN — Could not reach Keycloak at ${BASE_URL}"
  exit 2
fi

# Try to extract version from page or headers
VERSION=$(echo "$LOGIN_PAGE" | grep -oP '"keycloakVersion"\s*:\s*"\K[^"]+' 2>/dev/null || true)

if [[ -z "$VERSION" ]]; then
  # Try server header
  VERSION=$(curl -skI --max-time 10 "${BASE_URL}/realms/master/.well-known/openid-configuration" 2>/dev/null | grep -i 'x-keycloak-version' | awk '{print $2}' | tr -d '\r' || true)
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — Could not determine Keycloak version at ${BASE_URL}"
  echo "Manually verify: version must be >= 26.7.2 (upstream) or RHBK >= 26.4-23 / 26.6-12"
  exit 2
fi

echo "Detected Keycloak version: ${VERSION}"

# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VERSION" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')"

if [[ -z "$MAJOR" || -z "$MINOR" || -z "$PATCH" ]]; then
  echo "UNKNOWN — Could not parse version: ${VERSION}"
  exit 2
fi

# Fixed in 26.7.2 (upstream)
# Versions < 26.7.2 are vulnerable
if (( MAJOR < 26 )); then
  echo "VULNERABLE — Keycloak ${VERSION} is affected by CVE-2026-18963"
  echo "Upgrade to 26.7.2 or later immediately."
  exit 0
elif (( MAJOR == 26 )); then
  if (( MINOR < 7 )); then
    echo "VULNERABLE — Keycloak ${VERSION} is affected by CVE-2026-18963"
    echo "Upgrade to 26.7.2 or later immediately."
    exit 0
  elif (( MINOR == 7 && PATCH < 2 )); then
    echo "VULNERABLE — Keycloak ${VERSION} is affected by CVE-2026-18963"
    echo "Upgrade to 26.7.2 or later immediately."
    exit 0
  else
    echo "PATCHED — Keycloak ${VERSION} includes the fix for CVE-2026-18963"
    exit 1
  fi
else
  echo "PATCHED — Keycloak ${VERSION} includes the fix for CVE-2026-18963"
  exit 1
fi

Sources

1. Red Hat CVE Advisory
2. NVD Entry
3. Keycloak 26.7.2 Release Notes
4. Keycloak Market Share — 6sense
5. Keycloak Market Share — Enlyft
6. Keycloak Exposure Data — Shodan/Censys via ayinedjimi-consultants.fr
7. Red Hat Errata for RHBK