mcp-kubernetes-server does not correctly enforce the --disable-write / --disable-delete protections when commands are chained. The server only inspects the first token to decide whether an operation is write/delete, which allows a read-like command to be followed by a write action using shell metacharacters (e.g., kubectl version; kubectl delete pod <name>). A remote attacker who can invoke the server may therefore bypass the intended write/delete restrictions and perform state-changing operations against the Kubernetes cluster.
Affected versions: through 0.1.11 (no patched release available as of now).
Mitigations:
- Run with --disable-kubectl and/or --disable-helm to fully block those execution paths.
- Put the server behind an allow-list proxy restricting allowed subcommands.