CVE-2026-46519: mcp-server-kubernetes: auth bypass enables full cluster RCE

GHSA-cr22-wjx7-2w6m HIGH CISA: ATTEND
Published May 21, 2026
CISO Take

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.

Sources: NVD GitHub Advisory ATLAS

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?

Initial Access
Attacker authenticates to the MCP server's HTTP endpoint using a valid MCP_AUTH_TOKEN, gaining legitimate but ostensibly restricted access as a low-privileged client.
AML.T0012
Tool Discovery
Attacker calls tools/list and observes only the permitted tools (e.g., kubectl_get), confirming the restriction mode is active and harvesting tool names usable in the execution layer.
AML.T0084.001
Authorization Bypass
Attacker sends a direct tools/call JSON-RPC request targeting kubectl_delete, exec_in_pod, or kubectl_generic — absent from the list but unconditionally executable due to missing authorization check in CallToolRequestSchema.
AML.T0053
Cluster Compromise
With cluster-admin service account permissions, attacker deletes critical workloads, execs into privileged pods to harvest secrets and credentials, or pivots to the Kubernetes API server for full cluster control.
AML.T0101

What systems are affected?

Package Ecosystem Vulnerable Range Patched
MCP Server K8s npm < 3.6.0 3.6.0
1.5K 1 dependents Pushed 16d ago 100% patched ~14d to patch Full package profile →

Do you use MCP Server K8s? You're affected.

How severe is it?

CVSS 3.1
8.8 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 30% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I High
A High

What should I do?

5 steps
  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 does CISA's SSVC say?

Decision Attend
Exploitation poc
Automatable No
Technical Impact total

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:

EU AI Act
Article 9 - Risk Management System
ISO 42001
Clause 6.1.3 - AI Risk Treatment
NIST AI RMF
MANAGE-2.2 - Mechanisms to respond to AI risks
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

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

agent frameworksKubernetes orchestrationMCP server deploymentsmulti-tenant AI platformsin-cluster AI pipelines

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

EU AI Act: Article 9
ISO 42001: Clause 6.1.3
NIST AI RMF: MANAGE-2.2
OWASP LLM Top 10: LLM06:2025

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: 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

Timeline

Published
May 21, 2026
Last Modified
June 11, 2026
First Seen
May 22, 2026

Related Vulnerabilities