GPU VulnDB

Database/Container, Kubernetes & orchestration

mcp-server-kubernetes: leading-dash arguments inject --server and leak the operator's kubeconfig token

CVSS 9.3CVE-2026-61459Container, Kubernetes & orchestrationcurated

Impact

The structured kubectl tools accept resourceType and name values beginning with a dash, slipping past assertNoDangerousFlags, so an attacker who controls those tool arguments can inject --server and point kubectl at an API server they run. The operator's bearer token from the loaded kubeconfig is then sent to that endpoint. Because an MCP server of this kind usually runs with a cluster-admin or near-admin kubeconfig, the stolen credential is full control of the cluster: scheduling pods on GPU nodes, reading every namespace's secrets, and draining or relabelling nodes. The arguments come from an LLM, so untrusted content the agent reads - a pod log, an issue body, a manifest - is enough to drive the injection. Fixed in 3.9.0.

Who can reach it

Anyone who can influence the arguments the agent passes to these tools: a prompt-injection payload in content the agent processes, or any user permitted to talk to the MCP server. No Kubernetes credentials of their own are needed - the point of the bug is that they borrow the server's.

What to do

Upgrade mcp-server-kubernetes to 3.9.0 or later and restart the MCP server process. Treat the kubeconfig the server loaded as exposed if it was reachable by untrusted input: rotate that service account token or client credential and review the API server audit log for requests from unexpected sources. Scope the server's kubeconfig to the least privilege it can work with rather than cluster-admin.

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.