CVE-2026-71469 exposes a Security Boundary Violation in the search-v2-api tokenReviews cache, and the critical analytical failure is treating this as a cache sizing problem when it's actually a classic input validation failure at a security boundary that was never formally defined.
The tokenReviews cache exists to optimize internal authentication decisions — it was never designed to receive untrusted data. When the v2 API exposed this endpoint to unauthenticated requests, the implicit trust model collapsed. The cache was built under the assumption that all tokens reaching it had already passed upstream identity resolution. That assumption was never codified as a security boundary; it was just how the code worked. An attacker doesn't need credentials or special knowledge. They send garbage tokens and the system obligingly creates permanent cache entries for each one.
The permanence of these entries is the exploit characteristic that elevates this beyond a typical DoS. Most cache exhaustion attacks require sustained traffic to maintain pressure. This doesn't. One attacker sending garbage tokens creates entries that survive pod restarts, scaling events, and redeployments. The only path to recovery is fixing the validation logic or manually flushing the cache — neither happens automatically. This converts an active DoS into a persistent compromise requiring active remediation.
Push on two questions to determine real-world severity. First: does the fix address token validation (rejecting unknown tokens before caching), or does it only add cache size limits that can still be exhausted with enough requests? A size limit is rate limiting for a vulnerability that exploits unbounded state, not unbounded throughput — an attacker with modest capacity will still win. Second: what's the shared infrastructure exposure? If search-api runs in a namespace alongside authentication or data-plane services, memory pressure on this pod can trigger OOM kills across the node. Single-tenant internal deployment is a nuisance; multi-tenant cluster with adjacent critical services is a critical infrastructure event.
The v1 carryover question matters for understanding threat model evolution. If this existed in v1 and was ported forward, it suggests security review wasn't integrated into the API upgrade workflow. If it's new to v2, it suggests the threat model wasn't reconsidered when expanding external access. Either way, it points to a process gap: the security implications of architectural decisions aren't being surfaced at the point where those decisions are made.
For operational response: treat this as acute exposure, not routine. The exploit requires no authentication, no special knowledge, and the permanence of entries means the window between CVE publication and full remediation is wider than usual. Deployers face the compound risk of public vulnerability knowledge before patch availability — and attackers can fill the cache during that gap.