CVE-2026-101333 in Keycloak
Summary
by MITRE • 09/28/2026
A flaw was found in the Micrometer user-event metrics listener of Keycloak, a solution for integrated identity and access management. The issue occurs when the listener is configured to include the idp tag. An unauthenticated attacker can send requests to the identity broker login endpoint using arbitrary provider aliases, causing the system to create an unlimited number of metric time series. This can lead to excessive memory consumption and degrade the performance of both the server and its monitoring tools.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Keycloak involves a critical resource exhaustion flaw within the Micrometer user-event metrics listener component. Keycloak serves as a comprehensive solution for integrated identity and access management, handling authentication flows that often involve external identity providers through an identity broker mechanism. The specific technical flaw arises when the system is configured to include the idp tag in its metric collection settings. Under normal operational conditions, this configuration allows administrators to track performance metrics associated with different identity provider interactions. However, the implementation fails to properly validate or limit the scope of these tags during runtime processing. This lack of validation creates a pathway for abuse where an unauthenticated attacker can interact directly with the identity broker login endpoint using arbitrary and non-existent provider aliases.
When such requests are sent, the metrics listener interprets each unique alias as a distinct metric time series that requires tracking in memory. Because there is no upper bound or sanitization mechanism to prevent the creation of new time series for invalid inputs, an attacker can rapidly generate thousands or even millions of these entries by cycling through different arbitrary aliases. This behavior directly leads to excessive memory consumption on the Keycloak server hosting the application. As the heap space fills up with unused metric data structures, the Java Virtual Machine may struggle to manage garbage collection efficiently, leading to increased latency and potential out-of-memory errors that can crash the service entirely.
The operational impact of this vulnerability extends beyond simple denial of service for the identity management system itself. Since Keycloak is often deployed as a central authentication hub for multiple enterprise applications, its degradation or failure disrupts access control across the entire organization. Furthermore, because the metrics are typically exported to external monitoring tools such as Prometheus or Grafana via Micrometer exporters, these systems also suffer from performance issues. The influx of high-cardinality metric data can overwhelm the time-series database backend used for storage and visualization, causing delays in alerting and making it difficult for security operations teams to monitor system health accurately during an active attack.
This vulnerability is classified under CWE-787: Out-of-bounds Write or CWE-400: Uncontrolled Resource Consumption, as the core issue lies in the unbounded allocation of memory resources due to insufficient input validation regarding metric dimensions. In terms of offensive security frameworks, this aligns with MITRE ATT&CK technique T1496: Resource Hijacking, where an adversary utilizes system resources for their own benefit or to cause disruption rather than stealing data directly. The attack vector is categorized as Network-based and requires no authentication, making it particularly dangerous in environments where the Keycloak login endpoints are exposed to untrusted networks without additional rate limiting or Web Application Firewall protections that specifically filter high-cardinality metric inputs.
To mitigate this vulnerability, administrators should immediately update their Keycloak instances to a patched version that addresses the validation logic within the Micrometer listener. In cases where an immediate patch is not feasible, temporary mitigations include disabling the idp tag in the metrics configuration if it is not strictly required for operational monitoring. Additionally, deploying rate limiting at the network perimeter or using reverse proxy configurations can help restrict the volume of login requests from single source IPs, thereby reducing the speed at which metric time series are generated. Regular auditing of metric cardinality and implementing strict limits on unique tag values in Micrometer exporters is also recommended to prevent similar high-cardinality attacks against monitoring infrastructure in broader application ecosystems.