CVE-2026-71470

This vulnerability in the search-v2-operator exposes a critical gap between what a CR-editor role appears to do and what it can actually reach. The operator accepts imageOverride, environment variables, and command arguments directly from Custom Resource fields, then executes them under a ServiceAccount with extensive impersonation permissions. This means compromising a CR editor — a role typically granted for normal application workflows, not administrative access — grants the ability to inject arbitrary images or environment variables that run with cluster-level privileges. The attack chain is deceptively simple: a CR editor modifies the search CR to specify a malicious container image or adds a secret-reading environment variable. The operator, faithfully applying the CR spec, spawns that workload using its privileged ServiceAccount. The escalation from "configure search" to "cluster impersonation" requires no admin compromise, no webhook mutation, and no RBAC override — only the ability to edit a Custom Resource that happens to be processed by an operator running with elevated tokens. The remediation has two layers. First, the operator must validate that CR fields like imageOverride cannot specify images the operator wouldn't otherwise pull — an allowlist approach rather than accepting arbitrary user input. Second, and more fundamentally, the operator's ServiceAccount should never have possessed extensive impersonation permissions in the first place. The RBAC scope was the primary guardrail; field validation is the belt-and-suspenders backup. What makes this particularly dangerous is the trust topology. The search operator sits at a hub in the cluster's authorization graph. Its compromise doesn't expose one workload — it exposes every resource that the operator's token can reach. When operators run with elevated permissions and accept configuration from relatively accessible CR fields, they become single points of failure whose actual blast radius far exceeds what their RBAC role appears to justify. The broader pattern matters more than this specific operator. CVE-2021-25741 and CVE-2022-3294 followed the same structure: CR field injection reaching privileged execution through an over-permissioned operator ServiceAccount. Each instance gets patched locally, but the abstraction — that CR fields touching pod spec are implicitly privilege-escalation vectors when paired with elevated tokens — never makes it into framework guidance or developer mental models. The operator ecosystem treats CR fields as configuration, not as executable inputs, and that assumption is precisely what enables this class of vulnerability to recur.

Reviewed through automated stages and approved by a human before publication.