CVE-2026-105306 in Keycloak
Summary
by MITRE • 10/05/2026
A flaw was found in the Dynamic Client Registration flow of the Keycloak identity and access management server. The issue occurs because the registration process fails to filter security-sensitive client attributes when a new client is created. An attacker with a valid Initial Access Token can register a client that bypasses audience checks during token introspection. This allows the attacker to view sensitive identity information, roles, and session details from access tokens belonging to other applications in the same realm.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified within Keycloak’s Dynamic Client Registration flow represents a critical failure in input validation and security attribute filtering during the initialization of new OAuth2 or OpenID Connect clients. This flaw specifically targets the mechanism by which external applications can self-register with an identity provider, a feature designed to streamline integration but requiring strict adherence to security policies. The core technical deficiency lies in the server’s handling of client metadata provided during this registration process. When a request is made using a valid Initial Access Token, the system accepts and persists configuration parameters without adequately sanitizing or restricting attributes that dictate token behavior. This lack of rigorous filtering allows an attacker to manipulate how subsequent access tokens are processed by the identity provider, fundamentally undermining the isolation boundaries between different client applications operating within the same realm.
From a technical perspective, the exploitation vector hinges on the ability to bypass audience validation checks during token introspection. Token introspection is a standard endpoint used by resource servers to verify the validity and scope of an access token presented by a user or service. By registering a maliciously configured client that exploits this flaw, an attacker can craft requests where the introspection process fails to correctly validate the intended audience (aud) claim. This misconfiguration effectively neutralizes one of the primary safeguards against cross-application data leakage in OAuth2 and OpenID Connect implementations. Consequently, when tokens issued for other legitimate applications are subjected to introspection through this compromised client configuration, the server returns detailed token claims that should have been restricted or filtered based on the requesting application’s scope and audience restrictions.
The operational impact of this vulnerability is severe, as it enables unauthorized access to sensitive identity information belonging to users across multiple services within a single realm. An attacker who successfully exploits this flaw can extract roles, session details, email addresses, and other personally identifiable information embedded in access tokens intended for different applications. This capability effectively breaks the trust boundary between distinct client applications that share the same Keycloak realm. The exposure of role data is particularly dangerous as it may reveal administrative privileges or high-level permissions associated with user accounts, potentially facilitating further privilege escalation attacks within the broader ecosystem. Furthermore, the ability to view session details allows for potential session hijacking or targeted phishing campaigns based on accurate knowledge of active sessions and user activity patterns.
This vulnerability aligns closely with CWE-20 Improper Input Validation, as the root cause is the failure to properly sanitize inputs received during client registration that influence security-critical behaviors. It also maps to ATT&CK technique T1528 Steal Application Access Token, where an adversary seeks to obtain tokens from legitimate applications to impersonate users or access resources without direct authentication. The flaw essentially allows for token theft and misuse by bypassing the intended audience restrictions that are supposed to limit which services can interpret specific token claims. This represents a significant deviation from secure coding practices regarding identity federation protocols, particularly in multi-tenant environments where strict separation of client contexts is paramount.
Mitigation strategies must focus on immediate remediation through software updates provided by Keycloak maintainers, as this issue has been addressed in subsequent releases that enforce stricter filtering rules for dynamic registration attributes. Administrators should ensure their systems are patched to the latest stable version containing these security fixes. In environments where patching is not immediately feasible, network-level controls such as Web Application Firewalls can be configured to monitor and restrict unusual patterns of client registration requests or introspection calls originating from untrusted sources. Additionally, reviewing existing dynamic clients for any anomalous configurations that might exploit similar logic flaws is recommended. Long-term defenses should include implementing stricter policies on which attributes are allowed during dynamic registration, ensuring that only a predefined whitelist of safe parameters can be modified by external registrants. Regular audits of client registrations and introspection logs will help detect potential exploitation attempts early, while enforcing the principle of least privilege ensures that even if such a flaw is exploited in other contexts, the blast radius remains contained.