CVE-2026-46519: mcp-server-kubernetes: auth bypass enables full cluster RCE
GHSA-cr22-wjx7-2w6m HIGH CISA: ATTENDmcp-server-kubernetes, an MCP server bridging AI agents to Kubernetes clusters, enforced tool restrictions only at the discovery layer (tools/list) while leaving the execution layer (tools/call) completely unguarded — any authenticated client could invoke kubectl_delete, exec_in_pod, or kubectl_generic regardless of the ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS configuration. The blast radius is severe in environments where the MCP server runs with cluster-admin permissions, which is documented as common in dev and staging deployments, effectively translating a single bypassed access control into full cluster compromise. A working one-line curl proof-of-concept is publicly documented in the advisory, making this trivially exploitable by low-skill attackers targeting exposed MCP HTTP endpoints in multi-client deployments. Upgrade to v3.6.0 immediately, restrict network access to the MCP endpoint, and audit Kubernetes service account permissions to enforce least-privilege as a compensating control.
What is the risk?
High risk with context-dependent blast radius. CVSS 8.8 reflects a network-exploitable, low-privilege attack requiring no user interaction with full confidentiality, integrity, and availability impact. Effective severity escalates significantly when the Kubernetes service account holds cluster-admin rights — a common misconfiguration the advisory explicitly acknowledges in dev and staging environments. The vulnerability is trivially exploitable via a direct JSON-RPC call with no special tooling required, and the public advisory includes a working PoC. Multi-client HTTP deployments using SSE or Streamable HTTP transports are the highest-risk pattern, as operators relied on the tool restriction env vars as a real security boundary between roles or users — a trust model that was entirely invalidated.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MCP Server K8s | npm | < 3.6.0 | 3.6.0 |
Do you use MCP Server K8s? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Patch: Upgrade mcp-server-kubernetes to v3.6.0 immediately — this is the only complete fix, applying the same filtering logic from ListToolsRequestSchema to the CallToolRequestSchema handler.
-
Network isolation: Restrict access to the MCP HTTP endpoint (port 3003 by default) to authorized clients only via Kubernetes NetworkPolicy, firewall rules, or service mesh policy — treat the endpoint as a high-privilege administrative surface.
-
Least-privilege service accounts: Audit and scope down Kubernetes service account permissions bound to the MCP server — do not run with cluster-admin in any environment accessible to multi-user MCP deployments; grant only the minimum verbs and resources required.
-
Detection: Review Kubernetes audit logs for kubectl_delete, exec_in_pod, kubectl_generic, or node_management operations originating from the MCP server service account that fall outside expected agent workflows.
-
Verify patched version in production:
npm list mcp-server-kubernetesor inspect the running container image tag.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-46519?
mcp-server-kubernetes, an MCP server bridging AI agents to Kubernetes clusters, enforced tool restrictions only at the discovery layer (tools/list) while leaving the execution layer (tools/call) completely unguarded — any authenticated client could invoke kubectl_delete, exec_in_pod, or kubectl_generic regardless of the ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS configuration. The blast radius is severe in environments where the MCP server runs with cluster-admin permissions, which is documented as common in dev and staging deployments, effectively translating a single bypassed access control into full cluster compromise. A working one-line curl proof-of-concept is publicly documented in the advisory, making this trivially exploitable by low-skill attackers targeting exposed MCP HTTP endpoints in multi-client deployments. Upgrade to v3.6.0 immediately, restrict network access to the MCP endpoint, and audit Kubernetes service account permissions to enforce least-privilege as a compensating control.
Is CVE-2026-46519 actively exploited?
No confirmed active exploitation of CVE-2026-46519 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-46519?
1. Patch: Upgrade mcp-server-kubernetes to v3.6.0 immediately — this is the only complete fix, applying the same filtering logic from ListToolsRequestSchema to the CallToolRequestSchema handler. 2. Network isolation: Restrict access to the MCP HTTP endpoint (port 3003 by default) to authorized clients only via Kubernetes NetworkPolicy, firewall rules, or service mesh policy — treat the endpoint as a high-privilege administrative surface. 3. Least-privilege service accounts: Audit and scope down Kubernetes service account permissions bound to the MCP server — do not run with cluster-admin in any environment accessible to multi-user MCP deployments; grant only the minimum verbs and resources required. 4. Detection: Review Kubernetes audit logs for kubectl_delete, exec_in_pod, kubectl_generic, or node_management operations originating from the MCP server service account that fall outside expected agent workflows. 5. Verify patched version in production: `npm list mcp-server-kubernetes` or inspect the running container image tag.
What systems are affected by CVE-2026-46519?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, Kubernetes orchestration, MCP server deployments, multi-tenant AI platforms, in-cluster AI pipelines.
What is the CVSS score for CVE-2026-46519?
CVE-2026-46519 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.38%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation AML.T0084.001 Tool Definitions AML.T0101 Data Destruction via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.6.0, mcp-server-kubernetes exposes three environment variables (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) documented as access controls for restricting which Kubernetes operations are available. These controls are enforced at the tool discovery layer (tools/list) but not at the execution layer (tools/call). Any client that knows a tool name can invoke it directly regardless of the configured restriction mode. The access control was effectively cosmetic. This issue has been patched in version 3.6.0.
Exploitation Scenario
An attacker operating a legitimately authenticated but restricted MCP client — for example, a developer AI assistant granted ALLOWED_TOOLS=kubectl_get — first calls tools/list and confirms they see only kubectl_get in the response. They then craft a direct JSON-RPC tools/call request targeting kubectl_delete with a target pod name and namespace, exactly as documented in the advisory's PoC. The server dispatches the call unconditionally, returning confirmation of pod deletion. In a staging cluster running with cluster-admin, the attacker iterates through exec_in_pod to access running containers, harvests secrets from pod environments, and pivots to the Kubernetes API server. In an agentic pipeline scenario, a compromised or prompt-injected AI agent with access to the MCP server endpoint exploits the same bypass to perform destructive Kubernetes operations far beyond its intended scope, potentially taking down production workloads or exfiltrating sensitive configuration data.
Weaknesses (CWE)
CWE-863 Incorrect Authorization
Primary
CWE-863 Incorrect Authorization
Primary
CWE-863 Incorrect Authorization CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2026-47250 6.1 mcp-server-kubernetes: flag injection steals K8s tokens
Same package: mcp-server-kubernetes CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Code Execution CVE-2025-2828 10.0 LangChain RequestsToolkit: SSRF exposes cloud metadata
Same attack type: Auth Bypass CVE-2025-53767 10.0 Azure OpenAI: SSRF EoP, no auth required (CVSS 10)
Same attack type: Auth Bypass CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Code Execution