Keycloak JWT algorithm confusion (CVE-2026-11800): forging federated identity in the EU public sector's dominant IdP

Background. JWT algorithm confusion is a long-known token-forgery class — public research dating to the mid-2010s showed that if a verifier trusts the attacker-controlled alg header field, an attacker can substitute the signing algorithm (classically RS256→HS256, treating the public RSA key as an HMAC secret, or downgrading to alg: none) to forge a validly-"signed" token. The defensive consensus has been settled for years: pin the accepted algorithm server-side and never let the token dictate it. CVE-2026-11800 is notable not because the class is new but because it lands in Keycloak, the dominant open-source identity-and-access platform across European public administration (and the upstream of Red Hat Build of Keycloak / Red Hat SSO), where a token-layer bypass collapses the entire federated-identity trust boundary.

What the flaw is. Keycloak 26.6.4 (released 2026-06-26) patches eight CVEs; the headline issue is CVE-2026-11800 (CVSS 8.1, CWE-347 Improper Verification of Cryptographic Signature): an attacker holding any valid client credential in a realm can forge an assertion in the JWT Authorization Grant flow by manipulating the algorithm field, bypassing signature verification to mint unauthorised access tokens and impersonate any federated user linked to the affected identity provider — including administrators (Keycloak Project, 2026-06-26; GitHub Advisory GHSA-gqj5-2xp5-3qmp, 2026-06-25; BSI WID-SEC-2026-2093, 2026-06-26). The prerequisite — a single low-privilege registered OAuth client — is a low bar in a multi-tenant realm with many onboarded applications.

Why the release matters beyond the headline. The same 26.6.4 release fixes CVE-2026-9800 (CVSS 8.1, CWE-1025 policy-enforcer authorization bypass: an authenticated attacker who places the configured access-denied-page path into a request URL as a path segment or query parameter bypasses role/scope/UMA permission checks) and a privilege-escalation path from group-admin to realm-admin (CVE-2026-9099), plus information-disclosure, XSS, disabled-client-re-enablement and scope-mapping-bypass issues. CVE-2026-11800 maps to T1550.001 (Application Access Token abuse) and, where MFA is policy-enforced at the IdP, T1556.006 (the token issuer is bypassed, so MFA is moot); CVE-2026-9800 maps to T1078.004 valid-account abuse with elevated privilege.

Affected / fixed. Upgrade to Keycloak 26.6.4 per the project release notes; Red Hat Build of Keycloak users apply the matching advisories (Red Hat issued RHSA errata for RHBK alongside the upstream release). Treat any internet-reachable Keycloak admin or token endpoint as priority.

Hunt and detection concepts (no IOCs). In Keycloak's own event log, alert on token issuances where the JWT alg does not match the realm's configured signature algorithm (e.g. HS256 appearing on a realm configured for RS256/ES256), and on CODE_TO_TOKEN/CLIENT_AUTH events that resolve to a user the requesting client should not be able to assert. For the policy-enforcer bypass, review access-enforcer logs for requests containing the access-denied-page path as a query parameter or trailing path segment. Correlate admin REST calls (POST /admin/realms/{realm}/clients, role-mapping changes) against accounts that were previously only group-admins (the CVE-2026-9099 vector). Pipe these into the SIEM as identity-tier detections, not just app logs.

Hardening / mitigation. Beyond patching: enforce an explicit algorithm allowlist in realm OIDC settings so the alg field cannot be downgraded (none/HS256 must be rejected where asymmetric signing is expected); review group-to-role mappings for any realm-admin delegation; tighten Registration Access Token expiry; and keep the admin console off the public internet. The structural lesson for any IdP — Keycloak or not — is that the token verifier must own the algorithm decision; the token must never be allowed to choose how it is verified.