A JWT, two CVEs, and a series of systems left open behind the administrator's back
A series of serious vulnerabilities has just been discovered in the identity and access management (IAM) system, affecting millions of users.
Overview
In modern identity management systems, JWT is considered a "certificate of trust" - once the signature is valid, the system usually assumes that the identity inside the token is also trustworthy. But what happens if that trust is no longer valid, while the system continues to grant access?
Two vulnerabilities, CVE-2026-1486 and CVE-2026-1529, in Keycloak exposed a problem more dangerous than source code errors or memory overflows: a logic flaw in trust decisions. No complex exploitation is needed, no user interaction is required; an attacker only needs a "properly signed" JWT - even if the identity issuing that token has been disabled or is no longer authorized.
This article provides a detailed analysis of how these two vulnerabilities work, why they are particularly dangerous in enterprise environments using SSO and external IdP, and how Keycloak 26.5.3 has patched these seemingly "small" discrepancies that could lead to unauthorized access on a large scale.
Introduction to Keycloak
Overview of Keycloak
Keycloak is an open-source Identity and Access Management (IAM) platform developed by Red Hat, designed to address the challenges of centralized authentication and authorization for modern systems. Instead of each application handling login, password management, and access rights on its own, Keycloak acts as an identity hub, simplifying and standardizing the entire authentication flow.
Keycloak fully supports popular standards like OAuth 2.0, OpenID Connect (OIDC), and SAML 2.0, allowing flexible integration with web applications, mobile apps, APIs, and microservices. This enables systems to implement Single Sign-On (SSO), federated identity, and centralized access control without having to build complex security mechanisms from scratch.
One of the core strengths of Keycloak is its ability to connect with multiple Identity Providers (IdP), including LDAP, Active Directory, or third-party IdPs like Google, GitHub, and Azure AD.
Keycloak Services
Keycloak provides a comprehensive set of services for managing authentication, authorization, and user identity.
Authentication and Single Sign-On (SSO)
User Identity Management
Authorization and Access Control Services
Identity Federation
Support for OAuth 2.0, OpenID Connect, and SAML standards
Token and Session Management
Administration, Monitoring, and Auditing
Support for Extension and Integration
Vulnerability Details
Vulnerability Description
CVE-2026-1486
Description: A critical security vulnerability in Keycloak, related to improper handling of authentication logic in the JWT Authorization Grant flow (according to OAuth 2.0 – RFC 7523).
CVSS score: 8.8
Severity: High
Impact: If successfully accessed, an attacker can access resources protected by Keycloak.
CVE-2026-1529
Description: A security vulnerability in Keycloak, stemming from insufficient validation of JWT-based invitation tokens used during user invitation and registration into an organization or equivalent management scope.
CVSS score: 8.1
Severity: High
Impact: If exploited, this vulnerability can lead to: Unauthorized self-registration, unauthorized access to organizational data and resources, or violation of tenant separation models in multi-tenant systems.
Scope of Impact
CVE-2026-1486
Affected:
- All versions of Keycloak before 26.5.3
Includes:
Keycloak upstream (community)
Red Hat Build of Keycloak (RHBK)
Not Affected:
- Keycloak 26.5.3 and above
CVE-2026-1529
Affected:
- All versions of Keycloak before 26.5.3
Includes:
- Versions supporting organization / invitation flow
Not Affected:
- Keycloak 26.5.3 and above
Details of the Vulnerability
First, as mentioned, both vulnerabilities CVE-2026-1486 and CVE-2026-1529, although they exist in different functions of Keycloak (JWT Authorization Grant and Invitation Flow), share the same core nature:
Keycloak technically validates the token correctly but makes incorrect trust decisions regarding context and lifecycle.
From this, an attacker can exploit what the system considers valid.
The first phase is probing the system with a goal: The system uses Keycloak, relies on JWT as a trust unit, and has dynamic trust boundaries (IdP, invitation, organization).
Once a specific target is identified, the attacker moves to the next phase called Trust Surface Mapping. The attacker does not look for technical bugs but seeks points where trust can be "outdated" or "unbound." There will be two main trusts.
If you read the above and still don't understand what trust is, in the context of Keycloak / IAM / OAuth / JWT, trust is: The system's decision that "This information is trustworthy and can be used to grant access." First, the attacker will identify Identity Providers that once existed:
The system once integrated with external IdPs.
JWT issuer has a domain different from the internal realm.
There are multiple different issuers in the observed tokens.
After this step, the attacker will prepare the modified Tokens for exploitation:
Correct format.
Correct structure.
But no longer in the correct trust context.
Token is then sent to Keycloak via:
OAuth token endpoint (JWT Authorization Grant)
Invitation accept/registration endpoint
At the Keycloak verification step, which is also the core issue, Keycloak will verify as follows:
Is the token in the correct format?
Is the signature valid?
But it does not fully check:
The current status of the IdP (CVE-1486).
Contextual constraints of the invitation (CVE-1529).
And of course, when verified this way, the consequences will affect the victim's system. The attacker gains: A valid access token or a valid account within the organization.
Consequences
Impact at the Authentication Layer
Authentication bypass.
Impersonation of valid users.
Role escalation.
Privilege Escalation
Change system configuration.
Create a backdoor user.
Grant permanent admin rights.
Export the entire user database.
Breaking the Trust Boundary Model
Cross-realm trust abuse.
Client impersonation.
Token reuse beyond allowed scope.
Lateral Movement Impact
Access sensitive data.
Take control of internal systems.
Pivot to other infrastructures.
Conclusion
The two vulnerabilities CVE-2026-1486 and CVE-2026-1529 in Keycloak are not flashy technical issues like memory overflow or remote code execution, but they are more dangerous in another aspect: they distort the core trust decisions of the authentication system.
In CVE-2026-1486, Keycloak continues to trust and authorize JWTs from a disabled Identity Provider, simply because the token signature remains valid. This breaks the critical assumption that disabling an IdP means ending trust. As for CVE-2026-1529, the authentication process for invitation tokens is not fully completed, opening up the possibility of unauthorized self-registration into the organization, bypassing administrative barriers designed to control onboarding.
Recommendations
Upgrade Version (MANDATORY)
Upgrade Keycloak to version 26.5.3 or higher
Applies to:
Keycloak upstream (community)
Red Hat Build of Keycloak (RHBK)
For CVE-2026-1486 – JWT Authorization Grant
Check the list of Identity Providers that have been disabled:
External IdP
OIDC / JWT-based IdP
For each disabled IdP:
Rotate or revoke signing keys
Ensure the old key is no longer trusted by any system
For CVE-2026-1529 – Invitation Token
Check if the system uses:
Organization
Invitation-based onboarding
If yes:
Review accounts created through invitation tokens
Pay special attention to users with:
Organization ID that doesn't match operational logic
Email not belonging to the expected domain
Enhance Operational Controls (Defense-in-Depth)
Enable and monitor events:
Token issuance
Organization join
Authentication via JWT grant
Integrate Keycloak logs with:
SIEM
SOC monitoring
