AI-to-Kubernetes tool mcp-server-kubernetes flaw leaks admin credentials (CVE-2026-61459)

A serious flaw has been found in "mcp-server-kubernetes," a popular bridging tool that lets AI assistants (such as Claude Desktop) operate "Kubernetes," the system for running many servers together, that could let the credentials managing the cluster (server fleet) be stolen and the whole infrastructure taken over. The identifier is CVE-2026-61459, and its severity is 9.8 out of 10, in the top tier.

This tool supports "MCP (Model Context Protocol)," a common mechanism for letting AI use "external tools," so that AI can run Kubernetes operation commands (kubectl) on your behalf. The flaw here is that if an attacker slips a crafted instruction into these operation commands, the administrator's key (credentials) that should go to your own servers is instead sent to the attacker's server. Affected are versions before 3.9.0, and the vendor has released a fix. If you use it, update to the latest version right now.

What is mcp-server-kubernetes

Kubernetes is now a standard platform for managing and automatically operating many servers and containers (small boxes that run apps) together. It is widely used as the foundation of corporate systems and cloud services. It is normally operated with a command called "kubectl."

mcp-server-kubernetes is a bridge for letting an AI assistant do this operating. The increasingly common MCP (Model Context Protocol) is a shared set of rules for letting AI use external tools (file operations, databases, and — here — Kubernetes). Integrate this tool into Claude Desktop, Cursor, or VS Code, and just by saying "scale up this app" or "show me the logs," the AI actually runs kubectl for you. With over 1,500 GitHub stars, it is used by people managing infrastructure with AI. Vulnerabilities in similar "AI-to-external" tools have been reported before, as with the unauthenticated-access vulnerability in the data connector mcp-pinot and the MCP-based takeover vulnerability in LiteLLM.

What is dangerous, and how far can the damage spread

This flaw is what specialists call "argument injection." If an attacker slips into the instructions (arguments) the AI passes to kubectl a special option beginning with a dash (-), it slips past the tool's safety check and hijacks how kubectl behaves. Specifically, the destination kubectl talks to (which should be your own Kubernetes) can be swapped for a server the attacker prepared. The U.S. National Institute of Standards and Technology (NIST) classifies this as abuse of command argument delimiters (CWE-88).

When this happens, kubectl sends the administrator's credentials (the key to operate the cluster) straight to the attacker's server as it communicates. Having stolen this key, the attacker can freely operate the entire Kubernetes cluster while impersonating the victim. That means defacing or deleting apps, exfiltrating internal data, abusing it for cryptocurrency mining, even breaking into other systems — the infrastructure can be seized wholesale. The severity of 9.8 reflects this "steal the admin's key and take over the infrastructure" scale of impact.

What is frightening is that the trigger can be pulled simply by an AI agent reading external information. For example, when you ask an AI to "check these logs" or "look at this issue ticket," if the attacker has planted instructions inside those logs or tickets, the AI may execute them as operation commands. This is a new danger common to the whole mechanism of giving AI tools, and just like the case where Kubernetes keys leaked from a migration tool, the administrator's "keyring" is a classic target.

Who targets this hole, and what happens

The likely exploiters are attackers seeking administrator credentials as a foothold into corporate infrastructure, and ransomware groups that mine cryptocurrency on hijacked clusters or hold data hostage for ransom. Kubernetes administrator rights are close to a "master key" that governs an entire corporate system, making them an extremely high-value target for attackers.

The flow of attack goes like this. Attackers plant crafted operation instructions in logs, tickets, or web pages that the AI agent reads, and the moment the victim has the AI process them, they make kubectl point to the attacker's server and send the administrator's key. The victim thinks they merely asked the AI for a routine task, while behind the scenes the key is siphoned off.

As a result, the targeted organization loses control of its Kubernetes cluster, has running services stopped, or has internal data taken wholesale. The mechanism of giving AI convenient tools is spreading fast, but if those tools receive external input unguarded, the AI can be abused as the attacker's proxy. AI being used for both attack and defense overlaps with the structure in which AI is accelerating attacks.

What is happening from a technical standpoint

In mcp-server-kubernetes, several kubectl-related flaws have been reported in succession. The central one is the following.

CVE-2026-61459: crafted arguments redirect kubectl to the attacker's server and steal the admin's key (severity 9.8)

This tool passes instructions received from the AI as kubectl options (arguments). The problem was that arguments beginning with a dash (for example, options like --server or --kubeconfig that fundamentally change kubectl's behavior) were allowed to slip past the safety check. An attacker uses this to swap kubectl's connection target for their own server. Then the administrator's authentication token (the Authorization: Bearer header) that kubectl sends with each request goes straight into the attacker's hands. No login is required (no privileges needed), and affected are versions before 3.9.0. The vendor fixed it in 3.9.0.

A recurring pattern: token leaks and command execution

Similar flaws have been found repeatedly in this tool. By passing crafted arguments to the general-purpose kubectl feature (kubectl_generic), there was a flaw that let the administrator's authentication token leak to an attacker's server (CVE-2026-47250, fixed in 3.7.0), and by slipping dangerous characters into operations like scaling and patching, a flaw that let arbitrary commands run on the server hosting the tool (CVE-2025-53355, fixed in 2.5.0). The common cause in all cases is that input passed from the AI was fed straight into kubectl or system commands. When the "input validation" of the part that gives AI its tools is weak, the tool itself becomes a springboard for attack — a textbook case.

Affected versions and countermeasures

The affected and fixed versions for each major flaw are as follows. Because the fix version differs for each, the sure way to resolve them all at once is to update to the latest available version (the latest at publication is the v4.0 line).

Beyond updating, it is important to give the AI the minimum necessary privileges. This tool also has a "read-only mode" that permits only reading. For uses that do not need to make changes, narrowing to read-only, and limiting the external data (logs and tickets) you let the AI agent read to trusted sources, narrows the room for exploitation.

What is confirmed, and what is still unknown

What you can do right now

The core countermeasure is clear. The top priority is to update mcp-server-kubernetes to the latest available version (CVE-2026-61459 is fixed in 3.9.0; the latest at publication is the v4.0 line). Fixed versions are available from the GitHub releases page and npm. Letting AI handle infrastructure operations is convenient, but the damage when your key is seized grows accordingly.

Also important is to narrow the privileges you give the AI agent and the range of external data you let it read. If you do not need to make changes, use read-only mode; do not let the AI process untrusted logs or tickets as-is; and limit which devices handle the administrator credentials (kubeconfig). From the standpoint of continuously checking dependency vulnerabilities in your OSS supply chain, such AI-integration tools are worth keeping under watch.

Frequently asked questions

Summary

This case is about how a convenient tool for letting AI operate Kubernetes fed the instructions passed from the AI into kubectl without checking them well enough, so that the connection target could be swapped for the attacker's server and the cluster administrator's credentials stolen. CVE-2026-61459 is severity 9.8, can be exploited without a login, and, moreover, the same tool has had similar holes found repeatedly. If the administrator's key is seized, it leads to the heavy damage of the whole infrastructure being taken over.

The saving grace is that the vendor has already released a fix. Updating to the latest version, narrowing the privileges you give the AI, and not processing untrusted external data as-is closes most entry points. The mechanism of giving AI tools is spreading fast, but if the tool neglects to validate the input it receives, the AI can become the attacker's proxy. Working on the assumption that convenience and danger are two sides of the same coin, it is worth making privilege design and updates a habit. If there is any new sign of exploitation, we will report it again.

References

• ▸ NVD - CVE-2026-61459
• ▸ GitHub Security Advisory - mcp-server-kubernetes (command execution)
• ▸ GitLab Advisory - CVE-2026-47250 (token leak)
• ▸ mcp-server-kubernetes official repository (GitHub)