GPU VulnDB

Database/Container, Kubernetes & orchestration

mcp-server-kubernetes: read-only and allowed-tool restrictions are not enforced at tool execution

CVSS 8.8CVE-2026-46519Container, Kubernetes & orchestrationcurated

Impact

The three environment variables operators use to run this MCP server in a read-only or non-destructive mode only filtered the tools/list response; tools/call executed anything a client named. Any LLM agent or user wired to a server believed to be read-only could delete workloads, drain nodes, read secrets, or otherwise exercise the full kubeconfig the server holds. On a GPU cluster that typically means the service account that schedules and evicts GPU pods, so a prompt-injected or careless agent can destroy running training jobs and queue state. The guardrail was cosmetic, so any audit that relied on it was wrong.

Who can reach it

Any client that can reach the MCP server endpoint and knows a tool name. No separate authentication beyond whatever fronts the MCP server; the server's own restriction mode provides none.

What to do

Upgrade mcp-server-kubernetes to 3.6.0 or later and restart the server process. Until then treat the server's kubeconfig as fully privileged and restrict it with RBAC on the Kubernetes side rather than the env vars; review audit logs for tool calls outside the intended mode.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.