CVE-2026-11800: Authentication Bypass via JWT Algorithm Confusion in Keycloak

Keycloak is an open-source identity and access management (IAM) solution that provides single sign-on, identity brokering, and OAuth 2.0 / OpenID Connect (OIDC) provider capabilities. Within its org.keycloak:keycloak-services module, Keycloak implements RFC 7523, the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. This extension allows clients to request access tokens from the Keycloak token endpoint using a cryptographically signed JWT assertion (urn:ietf:params:oauth:grant-type:jwt-bearer) issued by an external Identity Provider (IdP) or signed by a registered client key.

CVE-2026-11800 is an improper verification of cryptographic signature vulnerability (CWE-347), specifically classified as JWT algorithm confusion. The vulnerability resides in how Keycloak validates incoming JWT assertions against configured public keys during both the JWT Authorization Grant flow and federated client authentication. When verifying a signature against a trusted public key, the verification pipeline must strictly enforce that the algorithm declared in the JSON Web Signature (JWS) header matches the cryptographic key type expected by the server.

In affected versions of Keycloak (26.6.0 prior to 26.6.4), the base token validator failed to enforce that the signature algorithm was asymmetric when validating assertions backed by public keys. Furthermore, the internal key loading helper, HardcodedPublicKeyLoader, explicitly contained logic to parse raw public key bytes into a symmetric secret key if a symmetric HMAC algorithm (such as HS256) was requested during verification.

Consequently, an attacker possessing valid OAuth client credentials can bypass authentication controls by constructing a fraudulent JWT assertion claiming the identity of any federated user associated with the trusted IdP. By setting the JWS header alg parameter to HS256 and signing the payload using the target IdP's publicly known RSA, EC, or EdDSA public key bytes as the HMAC secret, the attacker compels Keycloak to validate the signature symmetrically and issue a valid access token.

The root cause of CVE-2026-11800 stems from two distinct architectural flaws in Keycloak's token verification and key management subsystems: permissive algorithm resolution in AbstractBaseJWTValidator and unsafe key type coercion in HardcodedPublicKeyLoader. Together, these flaws violate the core cryptographic boundary separating asymmetric public keys from symmetric shared secrets.

During the execution of a JWT Authorization Grant request or client assertion verification, Keycloak invokes AbstractBaseJWTValidator.validateSignatureAlgorithm(String expectedSignatureAlg). This method extracts the algorithm name from the unverified JWS header (jws.getHeader().getAlgorithm().name()). Prior to the patch, if an administrator did not explicitly configure a pinned expectedSignatureAlg on the Identity Provider or client profile, the validator accepted any registered ClientSignatureVerifierProvider matching the header's algorithm name without verifying whether the provider implemented an asymmetric or symmetric primitive.

Once the validator accepted HS256 from the token header, execution proceeded to resolve the verification key configured for the Identity Provider or client. When keys were loaded via HardcodedPublicKeyLoader, the loadPublicKey method inspected the requested algorithm to determine how to instantiate the KeyWrapper object. Alongside branches for RSA, EC, and EdDSA, the loader contained a branch checking JavaAlgorithm.isHMACJavaAlgorithm(algorithm).

When this conditional branch evaluated to true, HardcodedPublicKeyLoader set the KeyWrapper type to KeyType.OCT (octet sequence) and executed KeyUtils.loadSecretKey(Base64Url.decode(encodedKey), algorithm). This operation took the Base64-encoded public key string configured for asymmetric verification, decoded its raw bytes, and wrapped them inside a javax.crypto.SecretKey instance. The HMAC signature verifier then used this derived symmetric key to validate the incoming JWS signature, completing the algorithm confusion chain.

Upstream commits 6d61885f20ac59a2ff8b823fc9ed1f1ef1019951 and d343c7373dcc7bfeb9dc14de2309836299c81837 remediate the vulnerability by enforcing strict separation between asymmetric and symmetric validators and removing symmetric key coercion from public key loaders.

In services/src/main/java/org/keycloak/authentication/authenticators/client/AbstractBaseJWTValidator.java, the patch introduces a new hook method, isSymmetricAlgorithmAllowed(), which defaults to false. Inside validateSignatureAlgorithm, the validator now rejects the none algorithm explicitly and queries the Keycloak session for the ClientSignatureVerifierProvider corresponding to the JWS header's algorithm. If symmetric algorithms are disallowed, the validator checks signatureProvider.isAsymmetricAlgorithm() and terminates validation if the algorithm is not strictly asymmetric.

// File: services/src/main/java/org/keycloak/authentication/authenticators/client/AbstractBaseJWTValidator.java
 
protected boolean isSymmetricAlgorithmAllowed() {
    return false; // Secure default: disallow symmetric algorithms in base validator
}
 
public boolean validateSignatureAlgorithm(String expectedSignatureAlg) {
    JWSInput jws = clientAssertionState.getJws();
 
    if (jws.getHeader().getAlgorithm() == null) {
        return failure("Invalid signature algorithm");
    }
 
    String algorithmName = jws.getHeader().getAlgorithm().name();
 
    // Explicitly reject unsigned tokens
    if ("none".equalsIgnoreCase(algorithmName)) {
        return failure("Invalid signature algorithm");
    }
 
    // Enforce asymmetric algorithm requirement unless explicitly overridden
    if (!isSymmetricAlgorithmAllowed()) {
        ClientSignatureVerifierProvider signatureProvider = session.getProvider(ClientSignatureVerifierProvider.class, algorithmName);
        if (signatureProvider == null || !signatureProvider.isAsymmetricAlgorithm()) {
            return failure("Invalid signature algorithm");
        }
    }
 
    if (expectedSignatureAlg != null) {
        if (!expectedSignatureAlg.equals(algorithmName)) {
            return failure("Invalid signature algorithm");
        }
    }
    return true;
}

To preserve legitimate symmetric client authentication (specifically client_secret_jwt where a shared client secret is intentionally used with HMAC), the patch introduces a dedicated subclass, JWTClientSecretValidator.java. This class extends JWTClientValidator and overrides isSymmetricAlgorithmAllowed() to return true. Consequently, only authentication flows explicitly designed for shared secrets permit HMAC algorithms, while JWTAuthorizationGrantValidator and public-key client authenticators inherit the strict asymmetric enforcement.

// File: services/src/main/java/org/keycloak/keys/loader/HardcodedPublicKeyLoader.java
 
if (JavaAlgorithm.isRSAJavaAlgorithm(algorithm)) {
    kw.setType(KeyType.RSA);
    kw.setPublicKey(PemUtils.decodePublicKey(encodedKey, KeyType.RSA));
} else if (JavaAlgorithm.isECJavaAlgorithm(algorithm)) {
    kw.setType(KeyType.EC);
    kw.setPublicKey(PemUtils.decodePublicKey(encodedKey, KeyType.EC));
} else if (JavaAlgorithm.isEddsaJavaAlgorithm(algorithm)) {
    kw.setType(KeyType.OKP);
    kw.setPublicKey(PemUtils.decodePublicKey(encodedKey, Algorithm.EdDSA));
    kw.setCurve(kw.getPublicKey().getAlgorithm());
// REMOVED: Symmetric HMAC key loading from public key bytes
// } else if (JavaAlgorithm.isHMACJavaAlgorithm(algorithm)) {
//     kw.setType(KeyType.OCT);
//     kw.setSecretKey(KeyUtils.loadSecretKey(Base64Url.decode(encodedKey), algorithm));
} else {
    logger.warnf("Unrecognized or invalid algorithm %s for hardcoded public key", algorithm);
    kw = null;
}

In services/src/main/java/org/keycloak/keys/loader/HardcodedPublicKeyLoader.java, the patch completely removes the else if (JavaAlgorithm.isHMACJavaAlgorithm(algorithm)) block. If any caller attempts to load a hardcoded public key using an unrecognized or symmetric algorithm, the loader logs a warning and returns null. Additionally, the frontend administration console (JWTAuthorizationGrantAssertionSettings.tsx) was updated to filter the algorithm selection dropdown using cryptoInfo?.clientSignatureAsymmetricAlgorithms, preventing administrators from selecting symmetric algorithms in the UI.

The fix is comprehensive and addresses both the entry-point validation logic and the underlying cryptographic key loader. By removing the ability of HardcodedPublicKeyLoader to instantiate KeyType.OCT secret keys and enforcing isAsymmetricAlgorithm() at the validator layer, variant algorithm confusion attacks against public key authenticators are neutralized.

Exploiting CVE-2026-11800 requires specific configuration prerequisites and low-level privileges (PR:L). First, the target Keycloak realm must have an external Identity Provider configured to support the OAuth 2.0 JWT Authorization Grant flow, or a client configured for public-key JWT authentication without an explicitly pinned asymmetric algorithm. Second, the attacker must possess valid client credentials (client_id and client_secret or equivalent authentication) for an OAuth client authorized to initiate the urn:ietf:params:oauth:grant-type:jwt-bearer grant request.

To execute the attack, the adversary first obtains the public key associated with the target Identity Provider. In standard OIDC and OAuth 2.0 deployments, this public key is publicly retrievable via the Identity Provider's JSON Web Key Set (JWKS) URI (/.well-known/jwks.json) or SAML/OIDC metadata descriptors. The attacker extracts the raw encoded byte representation of the public key.

Next, the attacker constructs a JSON Web Token payload containing claims expected by Keycloak's authorization grant processor. This includes setting the issuer (iss) to the trusted Identity Provider's issuer URI, the subject (sub) to the identifier of the target federated user in the realm, the audience (aud) to the Keycloak realm's token endpoint, and a valid expiration timestamp (exp).

// Upstream integration test demonstrating the exploit mechanic
// File: testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/oauth/jwtauthorizationgrant/AbstractJWTAuthorizationGrantTest.java
 
@Test
public void testHS256AlgorithmConfusion() {
    JsonWebToken token = createDefaultAuthorizationGrantToken();
    // Sign the JWT using HMAC-SHA256 with the IdP's encoded public key bytes
    String encodedToken = new JWSBuilder()
            .type("JWT")
            .jsonContent(token)
            .hmac256(identityProvider.getKeys().getKeyWrapper().getPublicKey().getEncoded());
 
    AccessTokenResponse response = oAuthClient.jwtAuthorizationGrantRequest(encodedToken).send();
    assertFailure("Invalid signature algorithm", response, events.poll());
}

As demonstrated in the upstream integration test testHS256AlgorithmConfusion(), the attacker serializes and signs the token using HS256 (hmac256), supplying the DER-encoded public key bytes (getPublicKey().getEncoded()) as the HMAC key. The attacker then transmits an HTTP POST request to the Keycloak /protocol/openid-connect/token endpoint, authenticating with their valid client credentials and passing the forged JWT in the assertion parameter alongside grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer. On unpatched instances, Keycloak validates the HMAC signature and returns an access token scoped to the impersonated federated user.

CVE-2026-11800 carries a CVSS v3.1 base score of 8.1 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. The attack vector is Network (AV:N) because the token endpoint is typically exposed directly to external clients over HTTPS. Attack complexity is Low (AC:L) as public keys are designed to be publicly accessible and constructing an HMAC-signed JWT requires standard cryptographic libraries. Privileges Required is Low (PR:L) because the attacker must authenticate as a valid client permitted to use the JWT Authorization Grant flow, though no User Interaction (UI:N) is required.

The primary security impact is complete authentication bypass for federated identities and horizontal or vertical privilege escalation within the Keycloak realm. By controlling the sub claim in the forged assertion, a malicious or compromised client can impersonate any user linked to the trusted Identity Provider. This grants the attacker high confidentiality (C:H) and high integrity (I:H) impact, allowing unauthorized reading and modification of any application data or administrative APIs accessible to the impersonated accounts.

In multi-tenant or partner-federated architectures where a semi-trusted client is allowed to exchange assertions from an external IdP, a compromise of that single client secret allows the attacker to pivot and assume the identity of arbitrary federated users without compromising the upstream Identity Provider itself. Availability impact is rated as None (A:N) because the flaw does not provide a mechanism to exhaust system resources or disrupt service availability.

Current threat intelligence indicates an EPSS score of 0.003 (0.30%, ~22.83rd percentile), and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. The low probability of automated mass exploitation is directly attributable to the PR:L requirement, as opportunistic internet scanners cannot exploit the token endpoint without first acquiring valid realm client credentials and identifying a realm actively configured for the JWT Authorization Grant flow.

Organizations running upstream Keycloak between versions 26.6.0 and 26.6.3 must upgrade to Keycloak version 26.6.4 or later. Version 26.6.4 incorporates commits 6d61885f20ac59a2ff8b823fc9ed1f1ef1019951 and d343c7373dcc7bfeb9dc14de2309836299c81837, which unconditionally block symmetric algorithms during public key JWT validation and strip HMAC key conversion from HardcodedPublicKeyLoader.

For enterprise deployments utilizing the Red Hat build of Keycloak (RHBK) 26.6, administrators should apply the updates released in Red Hat Security Advisories RHSA-2026:30083 and RHSA-2026:30084. Specifically, container-based deployments on Red Hat Enterprise Linux 9 must update rhbk/keycloak-rhel9 and rhbk/keycloak-rhel9-operator to version 26.6-8 or later, and rhbk/keycloak-operator-bundle to version 26.6.4-2 or later. Legacy Red Hat Single Sign-On 7 (RHSSO 7) and Red Hat Data Grid 8 are not affected by this vulnerability.

> [!NOTE] > If immediate patching is not operationally feasible, administrators can mitigate the vulnerability in AbstractBaseJWTValidator by explicitly pinning an asymmetric signature algorithm on all Identity Providers and clients using JWT assertions.

To implement this configuration workaround, navigate to the Identity Provider settings or Client authentication configuration in the Keycloak Admin Console and set the expected signature algorithm explicitly to an asymmetric algorithm (such as RS256, ES256, PS256, or EdDSA) rather than leaving it as "Algorithm not specified". In AbstractBaseJWTValidator.validateSignatureAlgorithm, when expectedSignatureAlg is non-null, Keycloak enforces a strict string comparison (!expectedSignatureAlg.equals(algorithmName)) against the JWS header, rejecting any incoming token that attempts to downgrade the algorithm to HS256.