3 techniques observed across 1 entry — derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.1 · compare on the matrix · Navigator layer (JSON)
Initial Access TA0001
T1078.004Valid Accounts: Cloud Accounts×1
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.
Keycloak 26.6.4 fixed eight CVEs. The headline flaw is CVE-2026-11800, a JWT algorithm-confusion that lets an attacker with valid client credentials forge an assertion, bypass signature verification and impersonate any federated user behind the affected identity provider (GHSA-gqj5-2xp5-3qmp, BSI WID-SEC-2026-2093); the bundled CVE-2026-9800 is a separate policy-enforcer authorization bypass via incorrect URI comparison. Keycloak is the IdP of choice across European public-sector, healthcare and finance deployments — these are identity-plane breaks, not app bugs. Patch to 26.6.4.
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.
JWT Algorithm Confusion Vulnerability in Keycloak — enables attackers with valid client credentials to bypass signature verification by forging an assertion to create unauthorized access tokens and impersonate any federated user linked to the affected Identity Provider; CVSS 8.1