CVE-2026-1486: Keycloak Auth Bypass Vulnerability

CVE-2026-1486 Overview

A security flaw has been identified in Keycloak's jwt-authorization-grant flow that allows authentication bypass through disabled Identity Providers (IdPs). The vulnerability occurs because the server fails to verify whether an IdP is enabled before issuing tokens. The lookupIdentityProviderFromIssuer mechanism retrieves IdP configurations but does not filter for isEnabled=false status, allowing compromised or decommissioned IdPs to continue authenticating users.

Critical Impact

An attacker possessing the signing key of a disabled IdP can generate valid JWT assertions that Keycloak will accept, resulting in unauthorized access token issuance even after an administrator has explicitly disabled the IdP.

Affected Products

• Keycloak (versions not specified in advisory)
• Red Hat Single Sign-On (related products per RHSA-2026:2365)
• Red Hat build of Keycloak (related products per RHSA-2026:2366)

Discovery Timeline

• 2026-02-09 - CVE-2026-1486 published to NVD
• 2026-02-10 - Last updated in NVD database

Technical Details for CVE-2026-1486

Vulnerability Analysis

This vulnerability represents an Authentication Bypass flaw classified under CWE-358 (Improperly Implemented Security Check for Standard). The core issue lies in Keycloak's token exchange and JWT authorization grant processing logic. When a client presents a JWT assertion signed by an external IdP, Keycloak performs issuer validation by looking up the corresponding IdP configuration. However, this lookup process fails to include a critical check—whether the IdP is currently enabled in the system.

This design oversight creates a dangerous window of exploitation. When an organization disables an IdP—typically done when the IdP has been compromised, a business relationship has ended, or during security incident response—the expectation is that all authentication pathways through that IdP are immediately terminated. Instead, any entity that retained or obtained the IdP's signing key can continue to generate valid JWT assertions that Keycloak will honor.

The attack is network-accessible and requires the attacker to possess low-level privileges (specifically, access to the disabled IdP's signing key). No user interaction is required for exploitation.

Root Cause

The root cause is an incomplete security check in the lookupIdentityProviderFromIssuer function within Keycloak's JWT authorization grant processing code. The function retrieves IdP configuration based on the issuer claim in the JWT but omits filtering logic to exclude disabled IdPs from the lookup results. This means the isEnabled property of the IdP configuration is not evaluated during the token validation process.

Attack Vector

The attack exploits the network-accessible jwt-authorization-grant endpoint. An attacker with access to a disabled IdP's signing key can craft JWT assertions containing:

1. A valid issuer claim matching the disabled IdP's configuration
2. Appropriate subject and audience claims
3. A valid signature generated using the IdP's signing key

When submitted to Keycloak's token endpoint, the server processes the assertion through the vulnerable lookup mechanism. Since the disabled status is not checked, Keycloak accepts the assertion as valid and issues access tokens to the attacker.

The vulnerability mechanism involves the following sequence: First, an administrator disables an IdP in Keycloak (for example, due to a security incident or offboarding). The attacker, who has obtained the disabled IdP's signing credentials, then crafts a JWT assertion with valid claims and signature. Upon submitting this to Keycloak's token endpoint using the jwt-authorization-grant flow, the lookupIdentityProviderFromIssuer function retrieves the IdP configuration without checking the enabled status. Keycloak validates the JWT signature against the IdP's public key and issues a valid access token to the attacker, granting unauthorized access to protected resources.

For detailed technical analysis, refer to Red Hat Bug Report #2433347.

Detection Methods for CVE-2026-1486

Indicators of Compromise

• Token issuance events linked to IdPs that are currently in disabled state
• JWT assertions containing issuer claims matching disabled IdP configurations
• Unexpected authentication activity from IdPs that were recently decommissioned
• Access token grants without corresponding active IdP sessions

Detection Strategies

• Implement logging and alerting on all jwt-authorization-grant flow requests, correlating with IdP enabled status
• Create SIEM rules to detect authentication events from IdPs that appear in the disabled IdP list
• Monitor for token issuance patterns that don't match expected user behavior for disabled IdPs
• Review Keycloak audit logs for token grants associated with IdPs that have been disabled

Monitoring Recommendations

• Enable verbose logging for Keycloak's token endpoint and IdP lookup operations
• Establish baseline metrics for jwt-authorization-grant usage per IdP to detect anomalies
• Configure alerts for any token issuance attempts referencing IdPs in disabled state
• Implement real-time correlation between IdP configuration changes and subsequent authentication events

How to Mitigate CVE-2026-1486

Immediate Actions Required

• Apply security patches from Red Hat Security Advisories RHSA-2026:2365 and RHSA-2026:2366
• Audit all currently disabled IdPs and rotate their signing keys if compromise is suspected
• Review token grants issued since IdPs were disabled for potential unauthorized access
• Consider temporarily removing disabled IdP configurations entirely until patches are applied

Patch Information

Red Hat has released security advisories addressing this vulnerability. Organizations should apply the relevant patches based on their deployment:

• Red Hat Security Advisory RHSA-2026:2365
• Red Hat Security Advisory RHSA-2026:2366

For additional details, refer to the Red Hat CVE Analysis for CVE-2026-1486.

Workarounds

• Delete disabled IdP configurations entirely rather than simply disabling them
• Implement network-level restrictions on the token endpoint to limit access from trusted sources only
• Rotate signing keys for all IdPs before disabling them to invalidate existing key material
• Deploy additional authentication layers (MFA) that don't rely solely on IdP assertions

# Example: Remove disabled IdP configuration via Keycloak Admin CLI
# Replace <realm> and <idp-alias> with your values
kcadm.sh delete identity-provider/instances/<idp-alias> -r <realm>

# Verify IdP has been removed
kcadm.sh get identity-provider/instances -r <realm>