Kubectl MCP Server Drive-By RCE (CVE-2025-65719) and Archon OS SSRF Chain (CVE-2025-69443)
Visit one malicious webpage while kubectl-mcp-server is running and an attacker owns your Kubernetes cluster. OX Security published a three-target disclosure in May 2026 covering a drive-by RCE in the widely adopted kubectl-mcp-server (CVE-2025-65719), a server-side request forgery chain in Archon OS (CVE-2025-69443), and an SSRF in Microsoft's MarkItDown MCP server that Microsoft declined to patch. Collectively the three targets represent over 140,000 GitHub stars and 60,000 DockerHub downloads. The kubectl vulnerability was patched in January 2026 after a 79-day disclosure window; Archon OS dismissed the report outright; Microsoft called MarkItDown working as designed.
What happened
OX Security's research team published a three-target advisory in May 2026, each discovered while extending the broader MCP STDIO research that produced the April 2026 supply chain disclosure.
The headliner is CVE-2025-65719 in kubectl-mcp-server, an MCP server that lets AI assistants such as Claude and Cursor control Kubernetes clusters through natural language. The server binds an HTTP endpoint and uses Python's subprocess with shell=True to execute kubectl commands. An attacker tricks a victim into visiting a malicious website while the server is running. The browser reaches localhost, sends a crafted payload to the kubectl endpoint, and the shell=True parameter turns it into arbitrary command execution. No authentication required at any step. Full Kubernetes cluster compromise from a single page visit.
CVE-2025-69443 affects Archon OS, an AI agent management platform. OX found an SSRF chain that enables data exfiltration and lateral movement through internal services. Archon dismissed the report twice, telling researchers the app was local-only for now. The maintainers acknowledged awareness and deferred patching to a future public deployment phase.
The MarkItDown MCP server from Microsoft fetches arbitrary URLs without validation, enabling access to cloud infrastructure credentials including AWS EC2 instance metadata. Microsoft's MSRC told OX the behaviour is working as designed, noting the service binds to 127.0.0.1 by default and runs with user privileges. No CVE was assigned and no patch was issued.
The PolicyLayer angle
CVE-2025-65719 is a textbook case for why agent-side controls matter when vendors use shell=True and bind to localhost. The MCP server author made both choices in good faith and still produced a drive-by RCE. The defensive primitive that breaks this class of attack before the browser request fires: deny-by-default tool execution for any MCP server that accepts connections on a network-reachable port, with an explicit allowlist of approved tools and a manual approval gate for any tool that invokes a subprocess. If the agent cannot call the kubectl tool without a human confirming the specific cluster and command, the webpage-to-cluster path collapses.
The Archon SSRF case makes a different point. Archon's response, 'it's a local app for now', is the same reasoning that produced the MCPJam Inspector in-the-wild exploitation earlier this year. Tools labelled local get deployed remotely, behind proxies, inside CI environments, on developer laptops connected to VPNs. Scoping credential access per task, rather than relying on network locality as a security boundary, is the control that survives that journey.
The MarkItDown wontfix is the hardest case. Microsoft's argument is technically coherent: the default binds to localhost, the docs warn you, the process runs as the user. None of that stops an attacker who has any foothold in the agent's context from redirecting a fetch tool call at http://169.254.169.254/latest/meta-data/. The policy-layer defence: block all tool calls that produce URLs pointing to link-local, RFC-1918, or cloud metadata ranges, enforced as an output filter independent of what the server's documentation says.
Mitigations
Upgrade kubectl-mcp-server to version 1.2.0 or later. Never run the server while browsing untrusted websites; treat any MCP server with a network-accessible endpoint as requiring the same caution you would apply to a listening service. For Archon OS and MarkItDown, apply network-level isolation: bind to localhost only, block inbound connections from non-local processes, and use egress filtering to prevent fetch-based access to metadata services.
FAQs
When kubectl-mcp-server is running, it binds an HTTP endpoint reachable from localhost. A malicious webpage uses a browser-side request (or DNS rebinding) to reach that endpoint. The server passes the attacker-controlled payload to subprocess with shell=True, executing arbitrary commands in the kubectl process context. Because the server holds cluster credentials, full cluster compromise follows.
No. Microsoft's MSRC told OX Security the behaviour is working as designed. The server binds to 127.0.0.1 by default and is documented as a local tool. Microsoft did not assign a CVE. The SSRF to cloud metadata endpoint is demonstrable but unpatched.
Archon's maintainers acknowledged the SSRF finding but deferred patching to a future public deployment phase. The project considers itself a local application and does not regard current exposure as requiring an immediate fix. The CVE (2025-69443) is assigned but no patch timeline has been published.