CVE-2026-71469: search-v2-api DoS Vulnerability

CVE-2026-71469 Overview

CVE-2026-71469 is a denial-of-service vulnerability in the search-v2-api component. An unauthenticated remote attacker can send HTTP requests carrying unique, randomly generated bearer tokens. Each token creates a permanent entry in the unbounded tokenReviews cache. Because the cache is never properly evicted, sustained token submission exhausts memory in the search-api pod. The result is a crash of the search-api service and loss of search functionality for legitimate users. The flaw is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
An unauthenticated network attacker can exhaust memory in the search-api pod and cause a denial of service by submitting requests with unique bearer tokens.

Affected Products

search-v2-api component (see Red Hat CVE-2026-71469 Advisory for the exact product mapping)
Specific affected package versions are not enumerated in the current NVD entry
Refer to Red Hat Bug Report #2512148 for vendor tracking

Discovery Timeline

2026-08-12 - CVE-2026-71469 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-71469

Vulnerability Analysis

The search-v2-api service validates incoming bearer tokens by performing a TokenReview against the Kubernetes API. To reduce upstream calls, the service caches the result of each TokenReview keyed by the token itself. The cache has no maximum size, no eviction policy, and no time-based expiration governing invalid or unknown tokens.

An attacker exploits this design by issuing requests with randomly generated bearer tokens. Each unique token produces a new cache entry, even when the token is invalid. Because entries are retained indefinitely, memory consumption grows linearly with the number of unique tokens submitted.

Once memory pressure exceeds the pod's configured limits, the container is terminated by the orchestrator or the process crashes with an out-of-memory condition. The search service becomes unavailable until the pod restarts, at which point the attack can be repeated.

Root Cause

The root cause is missing resource governance on the tokenReviews cache. Neither entry count, memory footprint, nor entry age is bounded. The classification aligns with [CWE-770] because the allocation of cache entries is unrestricted and attacker-controlled.

Attack Vector

Exploitation requires only network reachability to the search-v2-api endpoint. No authentication, no user interaction, and no prior access are required. An attacker submits a high volume of HTTP requests, each carrying a distinct random bearer token in the Authorization header, until the pod exhausts available memory. Distributed sources amplify the effect and complicate rate-limit mitigations.

No verified exploit code is publicly available for this issue. See the vendor advisory for authoritative technical details.

Detection Methods for CVE-2026-71469

Indicators of Compromise

Sustained high request volume to search-v2-api endpoints where Authorization: Bearer values differ on every request
Steadily rising memory utilization on the search-api pod without a corresponding rise in legitimate query volume
Repeated OOMKilled events or pod restarts for the search-api workload
Elevated TokenReview failure rates in the Kubernetes API server audit log originating from the search-api service account

Detection Strategies

Correlate pod memory growth with the cardinality of unique bearer tokens observed per source IP over a rolling window
Alert on TokenReview requests from the search-api service account where the invalid-token rate exceeds a baseline threshold
Monitor Kubernetes events for OOMKilled reasons on pods labeled for search-api

Monitoring Recommendations

Instrument the tokenReviews cache with size and hit-ratio metrics and export them to your observability platform
Enable Kubernetes API server audit logging for TokenReview calls and forward to a centralized log store for cardinality analysis
Track ingress request rates broken down by unique Authorization header hash to identify token-flood patterns

How to Mitigate CVE-2026-71469

Immediate Actions Required

Apply the vendor-supplied patch as soon as it is available from the Red Hat CVE-2026-71469 Advisory
Restrict network exposure of the search-v2-api endpoint to authenticated internal clients only, using NetworkPolicy or an ingress allowlist
Deploy rate limiting in front of the search-api service to cap requests per source IP and per unique token

Patch Information

Consult the Red Hat CVE-2026-71469 Advisory and Red Hat Bug Report #2512148 for fixed package versions and update procedures. The remediation is expected to introduce a bounded cache with size limits and time-based eviction for TokenReview entries.

Workarounds

Configure aggressive Kubernetes memory limits combined with livenessProbe restarts to reduce dwell time during an attack
Place an authenticating reverse proxy in front of search-v2-api to reject requests bearing invalid or unknown tokens before they reach the cache
Apply a Web Application Firewall rule that rate-limits or blocks clients submitting high volumes of unique bearer tokens

bash

# Example NetworkPolicy restricting search-v2-api ingress to trusted namespaces
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: search-v2-api-restrict
  namespace: open-cluster-management
spec:
  podSelector:
    matchLabels:
      app: search-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              trusted: "true"
EOF