EUVD-2026-53384
GHSA-xj3w-m54w-h7p9
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable via standard API calls (AV:N), no special conditions once metrics are enabled (AC:L), low-privileged authenticated account required (PR:L), purely an availability impact with no data exposure.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
A flaw was found in the user-event metrics recording of Keycloak. When metrics are enabled, the system records raw error messages from failed account operations as Prometheus metric labels. Because these error messages can include user-supplied input like nonexistent client IDs, an authenticated user can create a massive number of unique metric entries, eventually exhausting system memory and causing the service to crash or become unavailable.
AnalysisAI
Prometheus metric label cardinality exhaustion in Red Hat Build of Keycloak allows any authenticated user to crash the service by flooding its metric store with unique entries. When the Keycloak metrics subsystem is active, failed account operations (such as login attempts referencing nonexistent client IDs) cause raw, unsanitized error strings to be registered as Prometheus label values; because Prometheus stores each unique label combination as a distinct time series, a low-privileged attacker can generate an unbounded number of distinct metric entries, consuming JVM heap until the process crashes or becomes unresponsive. No public exploit code and no CISA KEV listing exist at time of analysis, but the low attack complexity and broad authenticated-user surface make this a realistic denial-of-service risk in any deployment where metrics are enabled.
Technical ContextAI
Keycloak is Red Hat's open-source identity and access management (IAM) platform, widely deployed as the SSO backbone for enterprise Java and OpenShift ecosystems. It exposes a Prometheus-compatible metrics endpoint (via Micrometer/SmallRye Metrics) for operational observability. The flaw arises from a failure to sanitize or bound the cardinality of metric label values: when a user-event (e.g., a failed client authentication) produces an error string that includes attacker-controlled input - such as an arbitrary client_id - that string is passed verbatim as a Prometheus label value. Prometheus and Micrometer store one distinct in-memory time series per unique label combination, so an attacker who iterates through millions of synthetic client identifiers creates millions of distinct metric series. This is the classic 'high cardinality label' anti-pattern that Prometheus documentation explicitly warns against. Affected products per CPE data include Red Hat Build of Keycloak (multiple release trains), Red Hat Single Sign-On 7, Red Hat Data Grid 8 (which embeds Keycloak components), and Red Hat JBoss Enterprise Application Platform Expansion Pack. No CWE was assigned, but the root cause maps to CWE-400 (Uncontrolled Resource Consumption) - specifically unbounded metric label cardinality without rate-limiting or sanitization at the instrumentation layer.
RemediationAI
The primary remediation is to apply the vendor-issued patch once Red Hat publishes an updated package for the affected products; monitor https://access.redhat.com/security/cve/CVE-2026-16100 and the associated Bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=2501730) for patch availability and exact fixed versions, which were not confirmed in the data available at time of analysis. As an immediate compensating control, disable the Prometheus metrics endpoint entirely if it is not operationally required - this eliminates the vulnerable code path with no impact to Keycloak's core authentication functionality, only to observability dashboards. If metrics cannot be disabled, restrict network access to the metrics endpoint (typically exposed on a separate management port) to trusted monitoring infrastructure only, using firewall rules or Keycloak's management interface access controls; this limits the exploitable surface to already-trusted hosts rather than all authenticated users. Additionally, enforce strict rate-limiting on the Keycloak authentication API for all authenticated sessions to reduce the throughput available to an abusive account. Note that rate-limiting alone is insufficient if the attacker has a long time window - disabling or isolating the metrics endpoint is the more reliable workaround until a patch is applied.
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Mismatched handling of the HTTP/1 absolute-form request authority in Red Hat build of Quarkus and other affected Red Hat
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Same technique Denial Of Service
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today