CVE-2026-101333

Executive Summary

CVE-2026-101333 is a denial-of-service flaw in the Micrometer user-event metrics listener of Keycloak. When that listener is configured to emit the idp tag, an unauthenticated attacker can send requests to the identity broker login endpoint using arbitrary provider aliases, forcing the creation of an unbounded number of metric time series. The result is excessive memory consumption and degraded performance of both the Keycloak server and the monitoring stack (e.g., Prometheus) that scrapes it. It affects Keycloak deployments that have enabled Micrometer event metrics with the idp tag; the CVSS base score is 3.7 (Low), reflecting a high attack complexity and limited availability-only impact.

Technical Analysis

The vulnerability is a resource-exhaustion / uncontrolled-resource-consumption issue (CWE-770: Allocation of Resources Without Limits or Throttling). It lives in the Micrometer user-event metrics listener shipped with Keycloak, an integrated identity and access management solution.

Keycloak exposes an identity broker login endpoint through which users authenticate against external identity providers (IdPs). Each configured IdP is referenced by a provider alias. The Micrometer listener observes user events and records them as metrics. When the listener is configured to include the idp tag, the provider alias becomes a metric tag (label) value rather than being normalized or bounded.

Because the identity broker login endpoint is reachable pre-authentication, an unauthenticated attacker can invoke it repeatedly while varying the provider alias in the request. Every distinct alias string produces a new tag combination, and therefore a new metric time series, in any tag-indexed/observability backend. Because nothing throttles, caps, or validates the number of distinct tag values, the cardinality grows without limit — the classic "high-cardinality label" failure mode. The NVD description does not disclose a specific parameter name, endpoint path, or code symbol for the alias, so the exact request field is not reproduced here; the mechanism is the generic provider-alias selector of the identity broker login endpoint.

Consequences are twofold. On the Keycloak server itself, unbounded series creation drives steady memory growth (metric registries and their tag indexes are held in memory), degrading request-handling performance and eventually risking memory pressure. On the monitoring side, every scraper or time-series database that ingests these metrics (Prometheus, and similar tag/index-based stores) must allocate storage and index entries per series, so the blast radius extends beyond Keycloak into the observability pipeline.

Two configuration facts determine exposure: (1) the Micrometer user-event metrics listener must be active, and (2) it must be configured to include the idp tag. The CVSS vector — AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L — is consistent with this: network-reachable, no privileges or user interaction required, high attack complexity (dependent on the specific listener configuration and on an unbounded alias supply), no confidentiality or integrity impact, and a Low availability impact. No public proof-of-concept, Nuclei template, or exploit code exists as of this report.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (unbounded tag cardinality / resource exhaustion) and the NVD description. Only the terms present in the description — Micrometer user-event metrics listener, the idp tag, the identity broker login endpoint, and provider aliases — are used. No specific query parameter, path, or function name is asserted because the source data does not provide one.

1. Reconnaissance / target identification. The attacker identifies internet- or network-reachable Keycloak instances (for example, hosts exposing the standard login/broker flows) and confirms that the deployment is running a Micrometer user-event metrics listener configured with the idp tag. This may be evidenced by observable metrics endpoints or by enumerating configuration in a test/lower environment that mirrors production.

2. Triggering the specific flaw class. From an unauthenticated position, the attacker sends requests to the identity broker login endpoint, supplying provider aliases that do not correspond to real IdPs (arbitrary strings). The endpoint is reachable pre-authentication, so no credentials are required. Because the idp tag is emitted for the event, each unique alias string creates a distinct metric time series.

3. Payload/execution at the class level. There is no memory-corruption or code-execution payload. The "payload" is high-cardinality input: a large volume of requests containing many distinct provider aliases. Loopers or distributed clients can generate thousands to millions of unique alias values. Each request also emits its own user event, so the load on the server and the metric store compounds.

4. Post-exploitation impact. The metric store's cardinality explodes, consuming memory and index/disk space on both the Keycloak server and the monitoring backend. The server’s request latency and throughput degrade; under sufficient volume, memory pressure can force restarts or OOM kills, taking authentication services offline. Because no integrity or confidentiality impact is present, the outcome is availability-focused (T1499). Persistence and lateral movement are not part of this vulnerability class; the practical goal is service degradation/DoS of Keycloak and its monitoring pipeline.

Impact Assessment

• CVSS 3.1 base score 3.7 (Low): AV:N, AC:H, PR:N, UI:N, S:U, C:N/I:N/A:L.
  • AV:N — the identity broker login endpoint is network-reachable.
  • AC:H — exploitation depends on specific listener configuration (Micrometer metrics enabled with the idp tag) and on the ability to generate unbounded distinct aliases.
  • PR:N / UI:N — unauthenticated, no user interaction.
  • C:N/I:N — no confidentiality or integrity impact; the flaw is availability-only.
  • A:L — limited availability impact (resource exhaustion/degradation rather than guaranteed total outage).
• Affected systems: Keycloak deployments with the Micrometer user-event metrics listener configured to include the idp tag, plus the observability stack (Prometheus/tag-indexed TSDB) that ingests those metrics.
• Blast radius: Single-domain within the vulnerable Keycloak instance, but with collateral degradation of the monitoring solution — meaning monitoring visibility may be lost precisely when incident response needs it most.
• Business impact: Authentication is a critical path; degradation or restart of Keycloak disrupts SSO for all dependent applications. Memory exhaustion can cause cascading failures, and high cardinality can pollute or stall the monitoring backend, impairing detection of other incidents. CISA KEV status: NO — no known exploitation in the wild is recorded.

Detection Guidance

Sigma Rule

title: Keycloak Identity Broker Login Endpoint Abuse - High Cardinality Provider Aliases
id: 8f1c9b2e-4d3a-4a7e-9c11-keycloak-micrometer-770
status: experimental
description: Detects a burst of requests to the Keycloak identity broker login endpoint carrying many distinct provider aliases, which creates unbounded metric time series when the Micrometer user-event listener includes the idp tag.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-101333
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1499
  - cve.2026-101333
logsource:
  category: webserver
detection:
  selection_method:
    cs-method: 'GET'
  selection_broker:
    cs-uri-stem|contains: 'broker'
  selection_login:
    cs-uri-stem|contains: 'login-actions'
  timeframe: 1m
  condition: (selection_broker or selection_login) and |count(c-ip) by cs-uri-query > 100
falsepositives:
  - Legitimate IdP configuration changes by administrators
  - Automated integration testing against the broker login flow
level: medium

YARA Rule

rule CVE_2026_101333_Keycloak_Micrometer_High_Cardinality
{
    meta:
        description = "Detects references to the identity broker login/provider alias flow combined with Micrometer idp-tag metrics configuration tied to CVE-2026-101333"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-101333"
        date = "2026-01-01"
    strings:
        $a1 = "user-event-metrics" nocase
        $a2 = "micrometer" nocase
        $a3 = "identity-broker" nocase
        $a4 = "provider-alias" nocase
        $b1 = "idp" wide ascii nocase
    condition:
        (any of ($a1, $a2)) and (any of ($a3, $a4)) and $b1
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-101333 Keycloak identity broker login - high-cardinality provider alias probing"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"broker"; http.uri; content:"login"; threshold: type both, track by_src, count 100, seconds 60; classtype:attempted-dos; reference:cve,2026-101333; sid:2026101333; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [http where url.path : "*broker*" and url.path : "*login*"] with runs=100

Explanation: flags a single source IP issuing 100+ requests to the broker login path within one minute, consistent with alias-cardinality abuse.

Splunk SPL Query

index=web OR index=proxy
| search uri_path IN ("*broker*", "*login-actions*")
| bin _time span=1m
| stats dc(uri_query) AS distinct_aliases count AS reqs by src_ip _time
| where reqs > 100 AND distinct_aliases > 50
| sort - distinct_aliases

Wazuh OSSEC Rule

<group name="web,accesslog,keycloak,">
  <rule id="100333" level="10" frequency="100" timeframe="60">
    <if_matched_sid>31101</if_matched_sid>
    <match>broker</match>
    <match>login</match>
    <description>CVE-2026-101333: Possible Keycloak identity broker login abuse - high-cardinality provider alias requests</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>cve_2026_101333,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix or workaround was provided.

1. Immediate mitigations

   • If the Micrometer user-event metrics listener is not strictly required, disable it, or remove the idp tag from its configuration. Eliminating the idp tag removes the attacker-controlled cardinality source entirely.
   • If the idp tag must remain, restrict/deny access to the identity broker login endpoint from untrusted networks and bound the number of provider aliases that can be presented, where the platform allows it.
   • Front the broker login endpoint with rate limiting / WAF rules keyed on distinct query parameters; alert on bursts of distinct aliases.
   • Raise memory limits only as a stopgap and increase scrapers’ ability to shed high-cardinality series; do not treat this as a fix.

2. Patch/upgrade steps

   • No patch is currently available (0/4 confidence). Monitor Keycloak and Micrometer security advisories and the NVD entry for CVE-2026-101333; apply the official fix as soon as it is published.
   • After upgrading, re-validate that the idp tag — if still used — is exposed in a bounded form.

3. Long-term hardening

   • Treat metric tag values derived from untrusted input as a cardinality risk; adopt a policy of allow-listing tag values and normalizing unknown values to a constant (e.g., unknown).
   • Enforce the principle of least exposure for identity broker login endpoints; review public reachability of all pre-authentication endpoints.
   • Add monitoring for metric cardinality growth and per-source burst detection to detect this and future resource-exhaustion classes (CWE-770).

References

• NVD — CVE-2026-101333: https://nvd.nist.gov/vuln/detail/CVE-2026-101333
• CWE-770 — Allocation of Resources Without Limits or Throttling: https://cwe.mitre.org/data/definitions/770.html
• MITRE ATT&CK — T1499 Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• Keycloak security advisories (monitor for a fix): https://www.keycloak.org/security
• FIRST — EPSS (score not yet assigned for this CVE): https://www.first.org/epss/ No known threat actor campaigns or in-the-wild exploitation evidence were available; CISA KEV status: NO.