mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519

What happened

CVE-2026-46519 is an access control bypass in mcp-server-kubernetes, an MCP server that exposes Kubernetes operations to AI agents as callable tools, affecting all builds prior to v3.6.0. The vulnerability carries a CVSS score of 8.8. The server reads environment variables - ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, and ALLOWED_TOOLS - that operators set to restrict which Kubernetes operations are permitted. It applies those restrictions correctly at the tool discovery layer, in the tools/list handler that builds the list a client is allowed to see. The enforcement is missing at the execution layer: the tools/call handler runs whatever tool name it is handed without rechecking it against the configured restriction mode.

The result is a disconnect between advertised and actual capability. A client never has to consult the filtered list - it can call a tool by name directly. An attacker or a misconfigured agent with network access to the HTTP endpoint can therefore invoke any tool the server implements regardless of the restriction mode, including kubectl_delete, exec_in_pod, kubectl_generic, and node_management. Because development and staging deployments commonly run this server with cluster-admin privileges, the bypass can hand over full control of the cluster. The fix in v3.6.0 adds the missing enforcement at the execution layer so the configured mode is rechecked before a tool runs.

This is not a parsing bug or an injection flaw. It is an authorization control that was implemented in one code path and forgotten in another - the same shape of mismatch between what a tool advertises and what it will actually do that recurs across the 2026 MCP CVE wave, and a close cousin of the execution-layer trust assumptions behind MCP STDIO execution by design.

Why this is an agentic-endpoint risk

An MCP server is not a passive dependency. It is code an AI agent invokes to act on real infrastructure, running with whatever privileges its deployment grants. mcp-server-kubernetes maps Kubernetes verbs to tools an agent can call, and a development instance with cluster-admin behind an HTTP endpoint is exactly the kind of high-capability surface that gets stood up bottom-up to unblock a workflow. The mcp-server-kubernetes access bypass turns a server an operator believed was locked to read-only into one that can delete workloads and exec into pods.

The exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The restriction is set in an environment variable that looks correct; the server reports a safe tool list; EDR sees a legitimate process; the network sees ordinary API traffic to a Kubernetes endpoint. MCP servers are one of the eight AI artifact types that are adopted without review and report to no security tool - the same dynamic that makes AI agents and MCP servers the new shadow IT. This is the artifact layer traditional controls were never built to see: the dangerous capability is encoded in a configuration mismatch, not in a known-bad binary or a malicious packet. You cannot tell which instances are exposed, or what they were actually allowed to do, without an inventory of the artifact layer and a record of every call.

How Anomity surfaces and governs it

Anomity addresses CVE-2026-46519 in three steps, and the structure matters because the lesson here is that filtering which tools are listed is not the same as governing which tool calls are permitted to execute.

First, inventory. Anomity inventories every MCP server on every managed endpoint as part of the eight AI artifact types it tracks, surfacing the exact version of mcp-server-kubernetes in use so finding everything prior to v3.6.0 is a single query rather than a fleet sweep. It captures the configuration metadata - including the restriction-mode variables set on each instance and the agent that talks to it - and classifies each server by the capabilities it grants. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A kubectl_delete, exec_in_pod, or node_management invocation is checked at the execution boundary even when the server itself would run it. That is precisely the control runtime governance is built to provide: enforcement on the actual tools/call, not on the advertised list, which is the exact gap CVE-2026-46519 leaves open.

Third, keep the record. Every decision, and every added, changed, or removed MCP server, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When responders ask which clusters were reachable through a vulnerable instance and what those tools were allowed to do, you answer from a record rather than a guess. None of this replaces patching - upgrade to v3.6.0 - but it closes the window before and after the fix is deployed, and it complements your Network, EDR, DLP, and GRC tooling by covering the layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint and container image for mcp-server-kubernetes and record its version; upgrade anything prior to v3.6.0 where the execution-layer fix lands.
• Treat any instance using ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS as currently unenforced at runtime until it is on v3.6.0 - the restriction filters the list only.
• Find every deployment whose HTTP endpoint is reachable beyond localhost and confirm it is not exposed to untrusted clients or agents.
• Stop running the server with cluster-admin in development and staging; scope its Kubernetes RBAC to the minimum the workflow needs so a bypass cannot escalate to full cluster control.
• Confirm high-risk tool calls - kubectl_delete, exec_in_pod, kubectl_generic, node_management - are evaluated at the agent hook with allow/deny/log, so a call is governed even if the server is not.
• Verify every tool call and server change is written to a 90-day audit trail and routed to your SIEM, so you can reconstruct what each instance was allowed to do.

CVE-2026-46519 is a reminder that an MCP server's advertised capability and its real one can diverge, and that the only place to close that gap reliably is at the call. Patch to v3.6.0, scope the server's cluster privileges down, and govern the destructive tools at the hook. For the full attack surface, MCP trust tiers, and the 2026 CVE wave this finding sits within, see the pillar guide on MCP server security, and the sibling advisory on MCP STDIO execution by design. To see Anomity inventory and govern the MCP layer across your fleet, request early access.