CVE-2026-16093: Keycloak Auth Bypass Vulnerability

CVE-2026-16093 Overview

CVE-2026-16093 is a security control bypass vulnerability in Keycloak's Client Policies mechanism. Client Policies allow administrators to enforce authentication requirements on clients, such as mandating signed JSON Web Tokens (JWTs) for authentication. The flaw allows an attacker with valid client credentials to submit a fake, unsigned assertion header that tricks the enforcement layer into accepting the request as compliant. The attacker then authenticates using a weaker method, such as a client secret, even when the administrator has mandated signed assertions. The issue is tracked under [CWE-807] (Reliance on Untrusted Inputs in a Security Decision).

Critical Impact
Attackers with valid client credentials can circumvent administrator-mandated signed JWT authentication and downgrade to weaker client secret authentication, undermining the integrity of client authentication policies.

Affected Products

Keycloak (Red Hat build of Keycloak) — see vendor advisory for affected versions
Red Hat Single Sign-On distributions incorporating Keycloak
Downstream products embedding vulnerable Keycloak releases

Discovery Timeline

2026-07-17 - CVE-2026-16093 published to NVD
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2026-16093

Vulnerability Analysis

Keycloak's Client Policies feature evaluates conditions and executors to decide whether an authentication request satisfies policy requirements. One common executor requires clients to present a signed JWT assertion, typically via the private_key_jwt client authentication method, instead of using a shared secret. The vulnerability arises because the policy engine trusts data supplied in the assertion header when deciding whether the signed-assertion requirement has been met. An attacker who possesses valid client credentials constructs an authentication request containing an unsigned assertion header crafted to pass the policy check. The policy engine records the requirement as satisfied, then falls back to authenticating the client using its shared secret. The attacker gains client-level access under an authentication method the administrator explicitly prohibited.

Root Cause

The root cause is reliance on untrusted input in a security decision, mapped to [CWE-807]. The policy enforcement path inspects an attacker-controllable field without verifying that the assertion is cryptographically valid or that the actual authentication method used matches the header contents.

Attack Vector

The attack is network-based and requires low privileges — specifically, valid credentials for a registered client. No user interaction is required. Exploitation depends on the target realm enforcing signed-assertion requirements through Client Policies. The vulnerability affects confidentiality and integrity of the authentication flow but does not directly impact service availability.

No verified proof-of-concept code is publicly available. Refer to the Red Hat CVE-2026-16093 Advisory and Red Hat Bug Report #2501729 for vendor-supplied technical details.

Detection Methods for CVE-2026-16093

Indicators of Compromise

Authentication events on the /token endpoint where the client_assertion_type parameter is present but the accompanying client_assertion is malformed, unsigned, or missing a valid signature.
Successful client authentications using client_secret_basic or client_secret_post for clients that are configured under a Client Policy mandating private_key_jwt.
Repeated token requests from the same client that mix assertion headers with secret-based authentication parameters.

Detection Strategies

Correlate Keycloak event logs with the configured client authenticator to identify clients authenticating with a method that contradicts their assigned Client Policy.
Parse CLIENT_LOGIN and CODE_TO_TOKEN events for assertion payloads and validate signatures out-of-band to spot forged headers.
Alert on any policy-governed client whose successful token issuance did not include a verified JWT signature.

Monitoring Recommendations

Forward Keycloak audit events to a centralized logging or SIEM platform and retain them for at least 90 days.
Monitor for spikes in token issuance from service accounts or machine-to-machine clients where signed assertions are required.
Track configuration drift in Client Policies and Client Authentication settings to detect unauthorized downgrades.

How to Mitigate CVE-2026-16093

Immediate Actions Required

Review the Red Hat CVE-2026-16093 Advisory and apply the fixed Keycloak build for your distribution as soon as it is available.
Rotate client secrets for any client governed by a signed-assertion Client Policy, in case secret-based fallback authentication was abused.
Audit realms for clients that use both a shared secret and signed JWT configuration, and eliminate the secret where the policy mandates private_key_jwt.

Patch Information

Red Hat tracks remediation under Red Hat Bug Report #2501729. Consult the vendor advisory for the specific Keycloak and Red Hat build of Keycloak versions that contain the fix, and follow the vendor's guidance for upgrading Operator-managed and standalone deployments.

Workarounds

Remove shared client secrets from clients that must authenticate with signed JWTs, forcing failure of any downgrade attempt.
Restrict network access to the Keycloak token endpoint so that only trusted clients can reach it, reducing exposure while patches are staged.
Enable strict client authenticator settings at the realm level and disable unused authentication flows that could be leveraged as fallbacks.

bash

# Example: disable client_secret_* fallback for a Keycloak client using kcadm
# Replace REALM and CLIENT_UUID with your environment values
kcadm.sh update clients/CLIENT_UUID -r REALM \
  -s clientAuthenticatorType=client-jwt \
  -s 'attributes."use.jwks.url"=true' \
  -s secret=""