Skip to content
eastbaycyber

CVE-2026-1609: Keycloak Disabled Users Can Obtain Tokens

CVE explainers 10 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-07-16
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - Keycloak 26.5.x before 26.5.3 can issue tokens for disabled users through the JWT authorization grant preview feature. - Affected teams should upgrade to 26.5.3 and review whether the preview grant is enabled. - No confirmed in-the-wild exploitation is cited in the available sources, but impact is high.

Vulnerability at a Glance

Field Value
CVE ID CVE-2026-1609
CVSS score 8.1
Attack vector Remote, via JWT authorization grant flow using a valid external IdP assertion token
Privileges required Low privileges, per NVD description
Patch available Yes, fixed in Keycloak 26.5.3

This issue affects Keycloak’s JWT authorization grant preview feature. The vulnerability is not a generic “all token issuance is broken” condition. It is tied to a specific flow where Keycloak processes a valid assertion token from an external identity provider and should reject token issuance if the mapped local user has been disabled.

The practical security concern is straightforward: disabling a user is often used as an immediate containment action during offboarding, incident response, or account compromise. If that disabled state is not enforced in one token issuance path, defenders can mistakenly believe access has been cut off when a working path still exists.

What Is This Vulnerability?

CVE-2026-1609 is an improper access control flaw in Keycloak. According to the NVD description, when the JWT authorization grant preview feature is enabled and a user account is disabled, Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. An attacker with low privileges can present a valid assertion token from an external identity provider and still obtain a JWT for that disabled user.

The root cause is not described as cryptographic weakness or token forgery. It is a state validation failure in the authorization logic. In other words, Keycloak should enforce the disabled status of the target user before issuing a token in this grant flow, but the vulnerable implementation did not do that consistently. The result is a bypass of an administrative control rather than a direct bypass of authentication itself.

For defenders, the most important technical distinction is that this only becomes relevant if the JWT authorization grant preview feature is enabled and used. That narrows the exposure compared with a default-path vulnerability, but the impact remains significant in environments that rely on federation with external identity providers and use disabled accounts as a hard stop.

Technical Notes

A simplified representation of the flawed logic looks like this:

if external_assertion_is_valid:
    map_assertion_to_user()
    issue_token()

# missing or ineffective check:
# if user.disabled == true: deny

The intended secure behavior is closer to:

if external_assertion_is_valid:
    user = map_assertion_to_user()
    if user.disabled:
        deny_token_request()
    else:
        issue_token()
AnalystImpact · assess the risk

Who Is Affected?

The clearest affected version information from the available sources is: upstream Keycloak 26.5.x prior to 26.5.3. The upstream Keycloak issue and 26.5.3 release notes tie the bug directly to the 26.5 line, and the release announcement identifies 26.5.3 as the fixed version.

The research note also surfaced an important scoping statement from the upstream issue: this feature is preview-only and “just affects upstream Keycloak 26.5”. It also states that RHBK 26.4 is not affected because the feature is not present in the downstream version. That means defenders should not assume all Red Hat build variants are affected in the same way as upstream Keycloak.

If you run Keycloak and are unsure whether you use this feature, assume exposure until proven otherwise if all of the following are true: you are on Keycloak 26.5.0, 26.5.1, or 26.5.2, you rely on an external IdP, and you have enabled the JWT authorization grant preview capability. If any of those facts are unknown, treat the system as potentially vulnerable until configuration and version are verified.

Affected and Fixed Versions

Product Affected Versions Fixed Version Notes
Keycloak Upstream 26.5.x before 26.5.3 26.5.3 Preview feature dependent
Red Hat Build of Keycloak (RHBK) No affected version confirmed in provided sources N/A Research note states RHBK 26.4 is not affected because the feature is absent

Technical Notes

Check the running version first:

bin/kc.sh --version

If Keycloak is containerized, identify the image tag in use:

docker ps --format "table {{.Names}}\t{{.Image}}"

Or with Kubernetes:

kubectl get pods -n keycloak -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

CVSS Score Breakdown

The published base score is 8.1, which places this flaw in the high-severity range. The exact vector string was not available in the provided NVD extraction, so defenders should avoid assuming unsupported sub-metrics. What is known from the vulnerability description is enough to understand why the score is high: the issue is remotely reachable through a token grant flow and can lead to unauthorized access to protected resources.

The impact is driven by a failure in identity enforcement. Disabled accounts are expected to be unusable. When that guarantee breaks, organizations can lose confidence in a foundational response action: disable the account and access stops. In many environments, this can affect internal apps, APIs, and administrative consoles protected by Keycloak-issued tokens.

Because the NVD text explicitly mentions a remote attacker with low privileges and unauthorized access to sensitive resources, practitioners should think of this as more than a narrow compliance issue. It is an operational control failure affecting account lifecycle enforcement, offboarding, and post-compromise containment.

Interpreting the Score Components

Component What Defenders Should Infer
Attack vector Remote, because exploitation occurs through a network-accessible authorization grant flow
Privileges required Low, per NVD description
User interaction Not stated in the provided sources
Scope Not stated in the provided sources
Confidentiality/Integrity/Availability impact Unauthorized access to sensitive resources is confirmed; exact subcomponent impacts were not provided

Where a metric component is unknown from the sources, the safest operational assumption is to focus on practical risk rather than wait for a perfect vector string. If the vulnerable grant path is enabled, treat the issue as externally reachable by parties able to submit valid IdP assertions.

Exploitation Status

Based on the available sources, there is no confirmed evidence of active exploitation in the wild. The research note confirms the CVE is not currently listed in the CISA Known Exploited Vulnerabilities catalog, which is a useful signal but not a guarantee of non-exploitation.

Also based on the provided references, no verified public proof-of-concept repository was identified. The publicly available materials cited are the NVD entry, the Red Hat CVE page, Red Hat Bugzilla, the upstream Keycloak GitHub issue, and the Keycloak 26.5.3 release notes. That means defenders should currently categorize exploitation status as: PoC not verified from available sources; active exploitation not confirmed.

This should not lead to complacency. Vulnerabilities affecting identity control planes are often attractive because they can undermine broad access boundaries. In the absence of public exploitation data, defenders should assume that motivated attackers can reproduce the issue from the advisory and fix context, especially when the affected code path is narrow and testable.

Technical Notes

Current public status from the provided research:

CISA KEV: Not listed
Public PoC: None verified in provided sources
In-the-wild exploitation: Not confirmed in provided sources

Operational assumption if telemetry is limited:

Assume exploitability is feasible in exposed environments
Prioritize patching if JWT authorization grant preview is enabled
Review disabled-user token issuance events retroactively
ResponderRunbook · act now

How to Detect It

Detection should focus on one question: did Keycloak issue tokens for accounts that are currently marked disabled? If your environment logs token grant events, user state changes, identity provider assertions, or admin actions that disable users, correlate those records. A successful token issuance tied to a disabled account is a strong indicator of either this vulnerability or another identity workflow problem.

Because the issue depends on the JWT authorization grant flow and an external IdP assertion, look for token endpoint activity associated with that grant type near the time an account was disabled. If your logging does not explicitly capture the grant type or disabled-state evaluation, you should still review token issuance to disabled identities, federation events, and access to sensitive applications after the disable action.

In many environments, the exact log format will vary by deployment model and logging backend. If you do not currently retain token issuance logs with username, client, and grant metadata, that is a gap worth addressing during remediation. In the absence of product-specific log documentation in the provided sources, defenders should focus on behavior-based detection rather than brittle field assumptions.

Technical Notes

Example log hunting pattern for suspicious sequences:

1. Admin or lifecycle event marks user as disabled
2. Subsequent token issuance event for the same username or subject
3. Grant context references JWT authorization grant or external assertion flow

Generic grep-style pattern to start with on consolidated logs:

grep -Ei 'disable|disabled|token|grant|assertion|identity provider|idp' /var/log/keycloak/*.log

Example pseudo-query for a SIEM:

SELECT timestamp, username, event_type, client_id, source_ip, details
FROM keycloak_events
WHERE username IN (
  SELECT username
  FROM keycloak_admin_events
  WHERE action IN ('DISABLE_USER','UPDATE_USER')
    AND details LIKE '%enabled=false%'
)
AND event_type IN ('TOKEN_ISSUED','LOGIN','IDENTITY_PROVIDER_LOGIN')
ORDER BY timestamp DESC;

Network-level detection is less reliable because this is legitimate application traffic to token endpoints, but defenders can still flag unusual assertion-grant bursts to the token endpoint from unfamiliar sources:

POST /realms/<realm>/protocol/openid-connect/token
Indicators of interest:
- repeated requests after account disablement
- requests tied to external IdP assertion workflows
- success responses for users expected to be blocked

Mitigation and Patching

The primary remediation is to upgrade to Keycloak 26.5.3 or later. The upstream Keycloak 26.5.3 release announcement explicitly lists the fix for this issue, and the research note ties the vulnerable range to 26.5.x before 26.5.3. If you are on that affected range, patching should be the first action.

If you cannot upgrade immediately, the most defensible workaround is to disable or stop using the JWT authorization grant preview feature until you can move to the fixed release. The research note makes clear that this vulnerability is tied to that preview feature. Because the exact configuration knob was not provided in the source material, administrators should consult their current realm and server configuration for any enabled preview feature flags related to JWT authorization grant and disable them as a temporary control.

A second mitigation step is to review all recently disabled accounts that federate through external identity providers. If those users still have valid workflows that can produce assertion tokens, consider additional containment such as revoking sessions, rotating trust relationships where appropriate, and adding compensating access controls at downstream applications until the Keycloak upgrade is complete.

Technical Notes

Upgrade Keycloak to the fixed version. Example container-based approach:

docker pull quay.io/keycloak/keycloak:26.5.3
docker stop keycloak
docker rm keycloak
docker run -d --name keycloak quay.io/keycloak/keycloak:26.5.3

Example Kubernetes image update:

kubectl set image deployment/keycloak keycloak=quay.io/keycloak/keycloak:26.5.3 -n keycloak
kubectl rollout status deployment/keycloak -n keycloak

Example validation after upgrade:

bin/kc.sh --version
# Expect: 26.5.3

If immediate patching is not possible, apply a workaround by removing exposure to the vulnerable flow. Because the exact feature flag syntax is not included in the provided sources, use a configuration review process like this:

grep -RinE 'preview|jwt|authorization grant|features' conf/ .

Then disable the preview JWT authorization grant feature according to your deployment’s existing Keycloak configuration method, restart the service, and verify that the affected grant path is no longer available. In the absence of documented syntax from the source material, do not guess in production. Use your current Keycloak configuration baseline and vendor documentation to make a controlled change.

References

The most authoritative references for this issue are the NVD entry, the vendor tracking page, the upstream issue, and the fixed release announcement. Together, they establish the product, root cause summary, vulnerable version scope, and fixed version.

Technical Notes

Reference-backed facts defenders can safely act on now:

Affected range: Keycloak 26.5.x before 26.5.3
Fixed release: Keycloak 26.5.3
Feature dependency: JWT authorization grant preview feature
Public PoC: None verified in provided sources
Known exploitation: Not confirmed in provided sources
KEV status: Not listed

For further reading on related vulnerabilities and best practices, check out our articles on why patching everything may be bad advice and CVE-2026-5118.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you. ```

Last verified: 2026-07-16

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.