--- schema: 1 kind: vulnerability title: > CVE-2026-18963 — Keycloak's password-reset flow can be driven to completion without the verification email being clicked, handing an unauthenticated attacker any account including administrators (CVSS 9.1) headline: > An identity provider's account-recovery path is the account-takeover path, and one affected Red Hat product has no fix at all summary: > Red Hat disclosed CVE-2026-18963 on 2026-08-18: a flaw in the reset-credentials flow of Keycloak's keycloak-services component lets an unauthenticated attacker force the password-reset process for any user without clicking the required email-verification link, then set new credentials directly and take full control of the account. Red Hat rates it Critical at CVSS 9.1 with no privileges and no user interaction required, and states the root cause is improper state validation in the reset-credentials authentication flow. Fixes shipped on 2026-08-18 in Red Hat build of Keycloak 26.4.15 and 26.6.6 — but the same component is recorded Affected with no erratum in the JBoss Enterprise Application Platform Expansion Pack, so part of the affected estate has no patch to apply. The two fixed streams are also not equivalent: 26.4.15 closes this flaw alone while 26.6.6 closes five, two of them further account-takeover and credential-disclosure paths on the same identity surface. Because the reset flow is reachable by anyone who can reach the realm, an administrator account served by that realm is takeable on the same terms. discovered_at: "2026-08-19T04:52:00Z" updated_at: null event_date: 2026-08-18 run_id: 2026-08-19T0410Z-intel priority: high immediate_action: null tags: - vulnerabilities - auth-bypass - pre-auth - identity - patch-available regions: - global - europe sectors: - public-sector - finance - healthcare - telco - technology entities: [] techniques: - T1190 - T1098 affected_products: - Red Hat build of Keycloak - Red Hat JBoss Enterprise Application Platform Expansion Pack cves: - id: CVE-2026-18963 cvss: "9.1" epss: null type: auth-bypass vector: zero-click auth: pre-auth status: - patch-available affected: > Red Hat build of Keycloak 26.4 (keycloak-services before 26.4.15) and 26.6 (keycloak-services before 26.6.6), including the RHEL 9 and OpenShift container images and the Keycloak operator bundles for both streams. Red Hat's product-state table records only two products as Not affected — the JBoss Enterprise Application Platform Expansion Pack and Red Hat Single Sign-On 7 — and lists no product as affected without a fix fixed: > Red Hat build of Keycloak 26.4.15 (RHSA-2026:56520; container and operator images RHSA-2026:56519) and 26.6.6 (RHSA-2026:56523; container and operator images RHSA-2026:56524), all released 2026-08-18. Every product Red Hat records for this flaw is either fixed by one of these errata or recorded Not affected sources: - url: "https://access.redhat.com/security/cve/CVE-2026-18963" publisher: Red Hat Product Security date: 2026-08-18 role: primary - url: "https://access.redhat.com/errata/RHSA-2026:56523" publisher: "Red Hat (RHSA-2026:56523, Keycloak 26.6.6)" date: 2026-08-18 role: corroborating - url: "https://euvd.enisa.europa.eu/enisa/eu_vulnerability_database/EUVD-2026-61063" publisher: ENISA EU Vulnerability Database date: 2026-08-18 role: corroborating - url: "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-18963.json" publisher: Red Hat Product Security (structured security data) date: 2026-08-18 role: primary closed_sources: [] evidence: - quote: The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link. publisher: Red Hat Product Security - quote: "The vulnerability's root cause is improper state validation within the reset-credentials authentication flow." publisher: Red Hat Product Security - quote: "disabling the \"Forgot password\" functionality across all realms can be used as a temporary mitigation" publisher: Red Hat Product Security (structured security data) verification: single-source sourcing_note: > Red Hat is both the vendor for its own Keycloak build and the CVE Naming Authority for this record, which is the vendor-PSIRT carve-out: the mechanism, the Critical rating, the CVSS vector, the root cause and the fixed releases all come from Red Hat's own advisory, read directly, including the four errata and the per-stream package states. No independent assessor has published on this flaw, there is no public proof-of-concept and no party reports exploitation, so the credibility rating stays at 2 rather than 1. The affected-and-fixed boundaries are transcribed from the advisory's structured package-state and affected-release data rather than its prose, which is what surfaced the second fixed stream (26.6.6) alongside 26.4.15, the JBoss EAP Expansion Pack row that is Affected with no erratum, and the Red Hat Single Sign-On 7 row that is Not affected. The four sibling CVEs are named from the 26.6.6 erratum's own security-fix list, read directly; they are recorded here to make the two streams' upgrade decisions comparable and are not otherwise assessed by this entry. Red Hat's advisory speaks only for Red Hat build of Keycloak; this entry therefore makes no claim about the upstream community distribution's status in either direction, because no source establishes one. confidence: medium references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: A credibility: 2 watchlist_hit: false actions: - "Upgrade Red Hat build of Keycloak to 26.4.15 on the 26.4 stream or 26.6.6 on the 26.6 stream, and update the matching RHEL 9 / OpenShift container images and operator bundles — patching the keycloak-services package alone leaves a deployment running the old image unfixed." - "If a JBoss Enterprise Application Platform Expansion Pack deployment was scoped as exposed to CVE-2026-18963 and given a compensating control or an open no-fix risk item, close it — Red Hat records that product's keycloak-services package as Not affected, so there is no exposure to mitigate and no erratum to wait for." - "Where Red Hat build of Keycloak 26.4.15 / 26.6.6 cannot be applied immediately, use Red Hat's own documented interim step — administration console, Realm settings, Login, Forgot password, Off — applied to every realm, in preference to blocking the reset path at the reverse proxy." updates: - at: "2026-08-24T08:55:00Z" run_id: 2026-08-23T1311Z-audit type: correction summary: > A correction to the 2026-08-19 coverage of CVE-2026-18963, the CVSS 9.1 unauthenticated account-takeover flaw in the reset-credentials flow of Red Hat build of Keycloak. That entry reported the Red Hat JBoss Enterprise Application Platform Expansion Pack as recorded Affected with no erratum, and concluded that part of the affected estate had no patch to apply. Red Hat's structured product-state data records the opposite: the Expansion Pack's keycloak-services package is "Not affected", the same state as Red Hat Single Sign-On 7, and those are the only two rows in the table — every other product Red Hat lists carries a shipped erratum. No Red Hat product is affected and unfixed. Red Hat also documents an official interim mitigation the earlier entry did not carry: turning off the forgot-password flow per realm in the administration console. fields: - actions - cves - evidence - sources - body merged_from: 2026-08-24/cve-2026-18963-keycloak-no-red-hat-product-unfixed - at: "2026-08-28T15:00:00Z" run_id: 2026-08-28T1500Z-audit type: improvement internal: true summary: > v4.2 migration: updated_at recomputed under the new float rule (only type: update records move updated_at; corrections/improvements no longer re-float the entry). fields: [actions, updated_at, body] migrated_from: null --- Red Hat published CVE-2026-18963 on 2026-08-18 against the reset-credentials flow in `keycloak-services`, the component it describes as the core engine for identity and access management in its Keycloak build. The flaw "allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link" ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/security/cve/CVE-2026-18963)), after which the attacker sets new credentials directly and holds the account. Red Hat's own assessment rates it Critical, exploitable by a remote unauthenticated attacker with no user interaction, and names the cause: "The vulnerability's root cause is improper state validation within the reset-credentials authentication flow" ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/security/cve/CVE-2026-18963)). ENISA's database carries the record with the same CVSS 9.1 and the same vector ([ENISA EUVD, 2026-08-18](https://euvd.enisa.europa.eu/enisa/eu_vulnerability_database/EUVD-2026-61063)). What makes this worse than its score is where it sits. Keycloak is not an application — it is the thing applications delegate authentication to, so an account taken over here is taken over everywhere that realm fronts. The email-verification click is the entire control standing between an anonymous request and a credential change, and the flaw is that the flow's state is not validated well enough to require it. That also means the usual compensating controls sit on the wrong side of the problem: multi-factor policies and password strength rules govern authentication, while this path rewrites the credential before authentication happens, and an administrator account reachable through the same realm's recovery flow is exposed on exactly the same terms as an ordinary user. The remediation detail matters more than usual, and in three separate ways. First, there are two supported streams, not one: Red Hat's errata fix the `keycloak-services` package in Red Hat build of Keycloak 26.4.15 (RHSA-2026:56520) and 26.6.6 (RHSA-2026:56523), with the RHEL 9 and OpenShift container images and the operator bundles carried in separate errata for each stream — RHSA-2026:56519 for 26.4 and RHSA-2026:56524 for 26.6, all released on 2026-08-18 ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/security/cve/CVE-2026-18963)). A containerised or operator-managed deployment that updates only the package and keeps its existing image is not fixed. Second, and absent from the headline advisory view, one affected product has no fix at all. Red Hat's structured product state records the same `keycloak-services` component as Affected in the Red Hat JBoss Enterprise Application Platform Expansion Pack with no erratum attached, while Red Hat Single Sign-On 7 is recorded Not affected ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/security/cve/CVE-2026-18963)). An estate running the Expansion Pack therefore carries an unauthenticated account-takeover path with no vendor update available, which is a different operational position from "upgrade to 26.4.15 or 26.6.6" and needs the compensating control below rather than a patch ticket. Third, the two streams are not equivalent upgrades. The 26.4.15 erratum closes this flaw alone; the 26.6.6 erratum closes five, and two of the other four sit on the same identity surface — a predictable account-linking hash that enables account takeover via a malicious OIDC client (CVE-2026-15571), and vault-resolved rotated client secrets leaked through the Admin REST API (CVE-2026-17048) — alongside a hidden-group-metadata disclosure through the fine-grained-admin role-groups endpoint (CVE-2026-14613) and a time-of-check-to-time-of-use privilege escalation (CVE-2026-9796) ([Red Hat, RHSA-2026:56523, 2026-08-18](https://access.redhat.com/errata/RHSA-2026:56523)). For a 26.6 operator the upgrade is therefore a five-flaw identity-surface fix, two of which are themselves account-takeover or credential-disclosure paths; for a 26.4 operator it is one. Red Hat's advisory speaks for Red Hat's builds; it establishes nothing either way about the upstream community distribution, and no source read as of 2026-08-24 does, so operators on the community build have no vendor statement to act on rather than a confirmed exposure or a confirmed exemption. No exploitation is reported, there is no public proof-of-concept, and Red Hat publishes no exploitation detail. The flaw nonetheless demands attention ahead of the normal cycle on its own mechanics: an anonymous, single-flow path to administrative control of an internet-facing identity provider is trivially rediscoverable once the fix diff is compared, and the fix is public as of 2026-08-18. Detection concentrates on the credential-reset trail, which is the one place the attack must leave a record. In identity-provider audit telemetry, the durable signals are `UPDATE_PASSWORD` and reset-credentials events for an account with no preceding verification-email event in the same flow, credential resets for accounts that never requested one, resets for administrator or service accounts in realms where those accounts are not managed through self-service recovery at all, and a burst of reset-flow initiations from a single source against many usernames. In web-tier telemetry the reachable surface is the realm's `login-actions/reset-credentials` path. **Triage:** genuine forgotten-password traffic produces the same endpoints and the same event types all day, so volume is not the signal — the discriminators are the missing verification step inside a completed flow, the target being an account class that has no business using self-service recovery, and a successful authentication from a new source immediately following the reset. Session revocation is worth pairing with the upgrade: a credential rotated after a takeover does not by itself invalidate a session the attacker already holds. ## Correction — 2026-08-24T08:55:00Z The earlier entry read Red Hat's product-state table for CVE-2026-18963 as recording the Red Hat JBoss Enterprise Application Platform Expansion Pack as Affected with no erratum, and built a paragraph, a summary sentence and an action item on the conclusion that part of the affected estate had no patch available. That reading was wrong. Red Hat's structured security data records exactly two products under `package_state`, and both are `"fix_state" : "Not affected"` — the Expansion Pack's `keycloak-services` package, and Red Hat Single Sign-On 7 ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-18963.json)). Every other product Red Hat lists for this flaw appears under the shipped errata instead. The customer-portal page for the CVE embeds the same product-state data — `"state":"Not affected"`, with the justifications "Component not Present" for the Expansion Pack and "Vulnerable Code not Present" for Red Hat Single Sign-On 7 ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/security/cve/CVE-2026-18963)). **No Red Hat product is recorded as affected by CVE-2026-18963 and left without a fix.** The practical consequence is narrower than the original entry implied and points the other way. An operator running the Expansion Pack has nothing to remediate for this CVE, rather than an unpatchable unauthenticated account-takeover path — so a risk item raised on the strength of the earlier entry can be closed, and any compensating control applied to that product line specifically can be withdrawn. Nothing else about the flaw changes: the reset-credentials weakness in Red Hat build of Keycloak, its Critical rating, its CVSS 9.1 and the two fixed streams all stand exactly as previously reported, and an unpatched 26.4 or 26.6 deployment remains the priority. The same record also carries an official interim step the earlier entry did not have. Red Hat states that where an immediate upgrade is not possible, "disabling the \"Forgot password\" functionality across all realms can be used as a temporary mitigation", reached in the administration console under Realm settings, Login, Forgot password, Off, and applied to every realm ([Red Hat Product Security, 2026-08-18](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-18963.json)). This supersedes the reverse-proxy suggestion carried previously: turning the flow off in the product removes the vulnerable path for every client of that realm, where a proxy rule only covers traffic that traverses the proxy. The reading error is worth naming because the shape recurs. Red Hat's `package_state` block enumerates the products Red Hat has *assessed*, not the products that are *vulnerable*; each row carries its own `fix_state`, and membership in the list says only that the product was evaluated. The same holds for the CSAF `product_status` groups other vendors publish and for the per-product build lists in Microsoft's Security Update Guide. **Triage:** a product named on a vendor advisory page is not thereby in scope — the verdict field beside it is the claim, and a product absent from the errata list may simply have been ruled out rather than left unpatched.