MCP Server Kubernetes kubectl_generic Flag Injection Bearer Token Exfiltration (CVE-2026-47250) - ATR-2026-01984 (5489a2f4-d026-5712-ae5b-1952648baa9d)
Detects CVE-2026-47250 (CWE-88): the kubectl_generic tool in mcp-server-kubernetes passes user-supplied flags straight to kubectl with no allowlist. Via indirect prompt injection (e.g. a crafted JSON line planted in pod logs an operator's agent later reads), the agent is coerced into calling kubectl_generic with --server=https://attacker.example.com together with --insecure-skip-tls-verify=true. kubectl normally suppresses the Authorization: Bearer <token> header over plain HTTP, so the attack needs BOTH flags together: the off-cluster --server redirect plus TLS verification disabled, which makes kubectl send the operator's bearer token to the attacker's endpoint. The captured token is then replayed against the real Kubernetes API server with the operator's full RBAC permissions. Affected: mcp-server-kubernetes before v3.7.0.
Detection covers: (a) a kubectl_generic flags object that sets both server (an http(s) URL)
and insecure-skip-tls-verify=true in the same call;
(b) the equivalent raw kubectl args form combining --server= with
--insecure-skip-tls-verify=true;
(c) explicit CVE-2026-47250 exploitation framing.
The detection target is the co-occurrence of the two flags in one tool call — that pairing is the exact token-exfiltration primitive the advisory documents, since kubectl only forwards the Authorization: Bearer header once verification is disabled. A normal single-flag kubectl_generic invocation (only --insecure-skip-tls-verify for a legitimate self-signed dev cluster, or only --server with TLS verification untouched) does not fire. A legitimate operator connecting to a genuinely trusted self-signed endpoint with both flags will also match; this is treated as a reviewable false positive, not silently allow-listed, because the co-occurrence is indistinguishable from the attack without out-of-band knowledge of which hosts are trusted.