Skip to main content
Vulnerability Database/CVE-2026-101333

CVE-2026-101333: Keycloak Micrometer Listener DoS Vulnerability

CVE-2026-101333 is a denial of service vulnerability in Keycloak's Micrometer user-event metrics listener that allows unauthenticated attackers to exhaust system memory. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-101333 Overview

CVE-2026-101333 affects the Micrometer user-event metrics listener in Keycloak, Red Hat's identity and access management solution. The flaw occurs when administrators configure the listener to include the idp tag. An unauthenticated attacker can send requests to the identity broker login endpoint using arbitrary identity provider aliases. Each unique alias causes Keycloak to create a new metric time series. The resulting cardinality explosion consumes memory and degrades the performance of both the Keycloak server and its monitoring infrastructure. The weakness is categorized under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact

Remote, unauthenticated attackers can exhaust server memory by injecting arbitrary identity provider aliases through the broker login endpoint, degrading availability of Keycloak and connected monitoring tools.

Affected Products

  • Red Hat Keycloak (Micrometer user-event metrics listener with idp tag enabled)
  • Red Hat Build of Keycloak
  • Red Hat Single Sign-On downstream distributions incorporating the affected listener

Discovery Timeline

  • 2026-09-28 - CVE-2026-101333 published to the National Vulnerability Database
  • 2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-101333

Vulnerability Analysis

Keycloak exposes operational telemetry through Micrometer, a vendor-neutral metrics facade. The user-event metrics listener emits counters for authentication-related events such as broker logins. Administrators can enrich these counters with tags, including an idp tag that labels each sample with the identity provider alias involved in the event.

Micrometer treats each unique combination of tag values as a distinct time series. The identity broker login endpoint accepts a provider alias in the request path or query string and emits a metric sample before validating that the alias corresponds to a configured provider. An attacker can therefore iterate through arbitrary alias strings and force the registry to allocate new time series for each one.

Unbounded cardinality drives sustained heap growth inside the Keycloak JVM. Scrape operations by Prometheus or similar collectors also enlarge, propagating resource pressure to the monitoring pipeline.

Root Cause

The listener uses attacker-controlled input as a metric tag value without enforcing an allowlist of known provider aliases or applying a cardinality cap. This matches the resource-exhaustion pattern described in CWE-770.

Attack Vector

Exploitation requires network reach to the Keycloak broker login endpoint and no authentication or user interaction. An attacker repeatedly issues requests to the identity broker login route while varying the provider alias parameter. Each request produces a new tag value, and the Micrometer registry grows until memory pressure impacts request latency, garbage collection, or stability. The vulnerability only affects deployments where the operator has explicitly enabled the idp tag on the user-event metrics listener.

No verified public proof-of-concept code is available. See the Red Hat CVE-2026-101333 Advisory and Red Hat Bug Report #2542498 for vendor-provided technical details.

Detection Methods for CVE-2026-101333

Indicators of Compromise

    • High volumes of HTTP requests to /realms/{realm}/broker/{alias}/login or /realms/{realm}/broker/{alias}/endpoint with alias values that do not match any configured identity provider.
    • Rapid growth in the number of distinct label combinations exported by the Keycloak Micrometer registry, particularly for metrics carrying the idp tag.
    • Elevated JVM heap usage, longer garbage collection pauses, and slower Prometheus scrape times correlated with the request pattern above.

Detection Strategies

    • Query access logs for the identity broker endpoints and group by provider alias; a long tail of single-use aliases from a small set of source IPs indicates probing.
    • Monitor the size of the Micrometer MeterRegistry using micrometer_core_meters_total or equivalent and alert on unbounded growth.
    • Compare the set of alias strings observed in HTTP traffic against the realm's configured identity providers and flag deviations.

Monitoring Recommendations

    • Track Keycloak JVM heap, GC frequency, and request latency alongside Prometheus scrape duration and payload size for early warning of cardinality abuse.
    • Forward Keycloak access logs and JVM metrics into a centralized analytics platform to correlate request patterns with resource exhaustion signals.
    • Rate-limit or geo-restrict access to the broker login endpoints at the reverse proxy layer and alert on sustained spikes.

How to Mitigate CVE-2026-101333

Immediate Actions Required

    • Review the Keycloak user-event metrics listener configuration and disable the idp tag if it is not required for operational dashboards.
    • Place a reverse proxy or web application firewall in front of Keycloak and restrict requests to /broker/{alias}/* paths that use unknown aliases.

Patch Information

Refer to the Red Hat CVE-2026-101333 Advisory and Red Hat Bug Report #2542498 for fixed package versions across Red Hat Build of Keycloak and Red Hat Single Sign-On. Upstream Keycloak users should track the corresponding community release notes and upgrade to the patched version once published.

Workarounds

    • Remove the idp tag from the Micrometer user-event metrics listener configuration until a patched build is deployed.
    • Configure a Micrometer MeterFilter to cap cardinality on affected meters, denying new tag values beyond the set of known identity provider aliases.
    • Enforce rate limiting on identity broker login endpoints at the ingress layer to reduce the rate at which attacker-controlled aliases can be introduced.
bash
# Example: restrict broker alias values at an NGINX reverse proxy
# Allow only known identity provider aliases; reject everything else.
location ~ ^/realms/[^/]+/broker/(?<alias>[^/]+)/ {
    if ($alias !~ ^(google|github|corp-oidc)$) {
        return 404;
    }
    proxy_pass http://keycloak_upstream;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.