Keycloak CVE-2026-1609

Exploitation requires that the JWT authorization grant (JWT bearer / RFC 7523) preview feature is explicitly enabled in Keycloak - it is disabled by default - and that the attacker can present a valid assertion token signed by an external identity provider that Keycloak trusts, mapping to a target user account that has been disabled by an administrator. The CVSS PR:L reflects that the attacker must supply valid IdP-issued assertion material rather than being fully unauthenticated. Limiting factors: default deployments without the preview feature are not affected; the attacker cannot exploit an arbitrary account without a corresponding valid external assertion; and impact is bounded to the privileges of the disabled account rather than arbitrary escalation. This is fundamentally an account-disable / deprovisioning bypass, not remote code execution.

The vendor CVSS 3.1 score is 8.1 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - network reachable, low complexity, requiring some existing privilege/authentication material (PR:L), no user interaction, high confidentiality and integrity impact, and no availability impact. Real-world risk is gated by two preconditions not reflected in the raw score: the JWT authorization grant preview feature must be explicitly enabled (it is off by default and preview features are not recommended for production), and the attacker must already hold a valid assertion token from a trusted external IdP for the target account. That makes this most dangerous as a privilege-persistence / offboarding-bypass issue - a deprovisioned insider or a compromised-then-disabled account retaining access - rather than mass-exploitable RCE. No EPSS score, POC, or KEV entry was provided in the input, so exploitation-probability signals are absent; treat that absence as unknown, not as low risk. SSVC-style read: exploitation=none observed, automatable=no (requires a valid IdP assertion per target), technical impact=partial-to-total. Priority is elevated specifically for organizations that have enabled this preview feature and rely on account disabling as a security control.

An employee is offboarded and their Keycloak account is disabled, but the JWT authorization grant preview feature is enabled and the attacker still possesses (or can obtain) a valid signed assertion for that account from a trusted external IdP. They present the assertion to Keycloak's JWT authorization grant endpoint, and because the disabled-status check is skipped they receive a fresh access token granting continued access to protected applications and data. No public POC was identified, but the low attack complexity (AC:L) and lack of required user interaction make the flow straightforward for anyone holding a valid assertion.