What is the CVSS score of CVE-2026-71469?

CVE-2026-71469 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.4%.

Which versions of Red Hat ACM are affected by CVE-2026-71469?

Red Hat Advanced Cluster Management for Kubernetes 2's search-v2-api component contains a memory exhaustion vulnerability allowing unauthenticated attackers to remotely crash the service by…

How to fix or mitigate CVE-2026-71469?

Within 24 hours, inventory all Red Hat Advanced Cluster Management for Kubernetes 2 deployments, confirm current product versions, and begin isolating the search-v2-api component from untrusted networks; note that no public exploit identified at time of analysis, though attack feasibility is high given unauthenticated access and low complexity requirements. Within 7 days, implement API rate limiting and request filtering rules to restrict bearer token submission rates, configure strict memory limits and automatic restart policies for the search-api pod, and restrict network access to search-v2-api to only known authorized clients. Within 30 days, monitor Red Hat security advisories for patch availability, establish continuous monitoring for pod memory consumption and unexpected restart events, and prepare immediate deployment procedures to apply patches as soon as they become available from the vendor.

Red Hat ACM CVE-2026-71469

EUVD-2026-57687 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-08-12 redhat

GHSA-6gx2-rqm4-38f9

Denial Of Service Red Hat Advanced Cluster Management For Kubernetes 2 Red Hat

7.5

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

AV:N and PR:N confirmed by unauthenticated HTTP token submission; A:H reflects full pod memory exhaustion; C:N and I:N as no data access or modification occurs.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 12, 2026 - 22:19 vuln.today

CVE Published

Aug 12, 2026 - 21:40 cve.org

HIGH 7.5

DescriptionCVE.org

A flaw was found in search-v2-api. An unauthenticated attacker can exploit this by sending requests with unique random bearer tokens. Each unique token creates a permanent entry in the unbounded tokenReviews cache, which is not properly cleared. This can lead to memory exhaustion of the search-api pod, resulting in a Denial of Service (DoS).

AnalysisAI

Memory exhaustion in Red Hat Advanced Cluster Management for Kubernetes 2's search-v2-api component allows unauthenticated remote attackers to crash the search-api pod by submitting HTTP requests with unique random bearer tokens. Each unique token creates a permanent, uncleaned entry in the unbounded tokenReviews cache; sustained submission accumulates entries until the pod exhausts available memory and is killed. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms trivial, unauthenticated exploitability with no prerequisites. No public exploit has been identified and the vulnerability is not listed in the CISA KEV catalog, though the low attack complexity makes automated exploitation straightforward.

Technical ContextAI

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling), a class of vulnerability where an application allocates memory for incoming data without enforcing an upper bound or eviction policy. In search-v2-api, the tokenReviews cache is designed to store results of token validation lookups; however, the cache is unbounded and entries are never evicted or expired. Because bearer tokens are user-supplied and arbitrary, an attacker can trivially generate an infinite stream of unique values, each forcing a new permanent cache entry. This is a Kubernetes-layer component - the affected product per CPE is cpe:2.3:a:red_hat:red_hat_advanced_cluster_management_for_kubernetes_2:*:*:*:*:*:*:*:*, meaning the search-v2-api runs as a pod within the RHACM-managed cluster and is accessible over the network without authentication. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H is consistent with the description: network-reachable, no complexity barrier, no credentials required, and exclusively an availability impact scoped to the vulnerable pod.

RemediationAI

No specific patched version has been identified in the available data - the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-71469 and Bugzilla ticket #2512148 should be monitored for a confirmed fix version and should be applied as soon as one is released. As interim compensating controls, enforce Kubernetes NetworkPolicy to restrict access to the search-v2-api service to only trusted internal consumers (e.g., RHACM operator namespaces), reducing exposure to unauthenticated external or intra-cluster requests; note this may break legitimate search integrations if misconfigured. Implement rate limiting at the ingress or service mesh layer to throttle token submission volume per source IP, which limits accumulation rate without requiring a code fix. Additionally, setting explicit memory limits on the search-api pod via its Deployment or Pod spec will cause the pod to OOM-kill and restart automatically rather than consuming node-level memory, containing the blast radius - though this does not prevent repeated restarts under sustained attack.