Keycloak released version 26.8.2 on November 5, addressing security issues across authentication, identity brokering, token handling and other components. For administrators, the upgrade also brings a practical change: tighter control over who can configure the protocol mappers that place identity information into tokens and assertions.
Account takeover risk depends on the login configuration
One fix covers CVE-2026-112208, an authentication bypass in the Organization identity-first login flow. Red Hat rates it Important, with a CVSS 3.1 score of 8.1. Exploitation requires the Organization feature to be enabled and the attacker to belong to at least two organizations. An authentication-state flag can survive a transition to registration or password reset, allowing the system to mistake stale state for proof of another user’s identity.
The project’s issue record identifies reproduction on 26.8.1. That is evidence of an affected release, rather than a complete affected-version range. The 26.8.2 release explicitly lists the issue among its security fixes.
A separate login-page issue, CVE-2026-107889, allows stored cross-site scripting through realm display fields. Red Hat assigns a 5.5 score and Moderate severity. It requires an attacker with manage-realm permission, who could place malicious content that executes JavaScript when users visit the affected realm’s login page.
The reviewed release and vulnerability notices do not report exploitation in the wild. The different prerequisites matter when assessing exposure; these are not interchangeable descriptions of an unauthenticated attack against every installation.
Check client automation before rolling out the patch
The 26.8.2 migration guide says creating, changing or deleting protocol mappers through the Admin REST API now requires realm-management permission by default. Delegated administrators who could previously manage clients may need explicit permission for selected mapper types.
Dynamic Client Registration is affected too. Permitted mapper types must satisfy both the realm-level allowlist and the registration policy. Because the realm-level list starts empty, registration workflows cannot add or alter mappers until an administrator configures the permitted types.
Before deployment, identify which provisioning jobs manage mappers and test those jobs with the new permissions. Review the migration notes for the version currently deployed, then validate normal login, registration and password-reset flows in a staging environment. Keep any delegation limited to the mapper types the workflow actually needs.
