--- title: "mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519" description: "CVE-2026-46519 (CVSS 8.8): mcp-server-kubernetes enforces tool limits at tools/list, not tools/call, so any client can run kubectl_delete. Fix in v3.6.0." url: "https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/" source: html --- On this page - What happened - Why this is an agentic-endpoint risk - How Anomity surfaces and governs it - What to check across your fleet - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519 ![Anomity robot illustrating mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519] Advisory High # mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519 Anomity Research Anomity Threat Research · Jun 11, 2026 · 6 min read Share: Copied MCP Server Security · High · CVE-2026-46519 · Jun 11, 2026 Affected mcp-server-kubernetes prior to v3.6.0 ## 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](https://anomity.ai/blog/mcp-server-security-complete-guide/), and a close cousin of the execution-layer trust assumptions behind [MCP STDIO execution by design](https://anomity.ai/blog/anthropic-mcp-stdio-by-design-rce/). ## 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](https://anomity.ai/#features) 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](https://anomity.ai/blog/ai-agents-are-the-new-shadow-it/). This is the artifact layer [traditional controls were never built to see](https://anomity.ai/#compare): 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](https://anomity.ai/#features) 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](https://anomity.ai/#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](https://anomity.ai/#outcomes), 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](https://anomity.ai/blog/mcp-server-security-complete-guide/), and the sibling advisory on [MCP STDIO execution by design](https://anomity.ai/blog/anthropic-mcp-stdio-by-design-rce/). To see Anomity inventory and govern the MCP layer across your fleet, [book a demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions Am I affected by CVE-2026-46519? You are exposed if you run any build of mcp-server-kubernetes prior to v3.6.0 with its HTTP endpoint reachable, even when you have set ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS to lock the server down. Those variables filter the tool list a client sees, but they do not stop a client that already knows a tool name from calling it. The fix landed in v3.6.0, which adds the missing enforcement at the execution layer. The first step is knowing where this server runs across your fleet and which version each instance is on, which needs an inventory of the AI artifact layer. What does the vulnerability allow an attacker to do? CVE-2026-46519 carries a CVSS score of 8.8. An attacker or a misconfigured agent with network access to the HTTP endpoint can invoke any tool the server implements regardless of the configured restriction mode, including kubectl_delete, exec_in_pod, kubectl_generic, and node_management. Because development and staging deployments commonly run the server with cluster-admin privileges, the bypass can hand over full control of the cluster: deleting workloads, executing commands inside running pods, and cordoning or modifying nodes. A read-only configuration provides no actual protection against a client that calls the destructive tool by name. Why did the restriction modes fail to block the calls? The server applies ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, and ALLOWED_TOOLS correctly at the tool discovery layer - the tools/list handler builds the advertised list with the restrictions applied. The enforcement is missing at the execution layer: the tools/call handler runs whatever tool name it receives without rechecking it against the configured mode. That creates a disconnect between advertised and actual capability. A client never has to read the list; it can call a tool directly. Filtering which tools are listed is not the same as governing which tool calls are permitted to execute. How does Anomity help with CVE-2026-46519? Anomity inventories MCP servers across every managed endpoint and surfaces the version in use, so finding every mcp-server-kubernetes instance prior to v3.6.0 is one query rather than a fleet hunt. On agents that expose a hook, it evaluates each tool call against your policy and returns allow, deny, or log before the call runs, so a kubectl_delete or exec_in_pod invocation is checked at the execution boundary even when the server itself would not. Every install, version change, and decision lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. ## Related [Advisory Critical ### mcp-atlassian HTTP Auth Bypass Falls Back to Global Credentials - CVE-2026-77254 CVE-2026-77254 (CVSS 9.1): unauthenticated HTTP MCP requests to mcp-atlassian below 0.22.0 fall through to globally configured Jira/Confluence credentials. Sibling CVE-2026-77244 (CVSS 10.0) accepts any non-empty token. Anomity Research · Sep 28, 2026 · CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx); sibling CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6)](https://anomity.ai/blog/mcp-atlassian-http-auth-bypass-global-credentials-cve-2026-77254/) [Advisory Critical ### GitLab MCP CVE-2026-61568 - Streamable HTTP DNS Rebinding to Localhost CVE-2026-61568 (CVSS 9.6): @zereight/mcp-gitlab Streamable HTTP skipped SDK DNS-rebinding Host/Origin allowlists on loopback - fixed in 2.1.30. Anomity Research · Sep 21, 2026 · CVE-2026-61568 (CVSS 9.6, GHSA-vmp7-252j-cwp7)](https://anomity.ai/blog/mcp-gitlab-streamable-http-dns-rebinding-cve-2026-61568/) [Advisory Critical ### MySQL MCP Server CVE-2026-59971 - Unauthenticated SQL via SSE DNS Rebinding CVE-2026-59971 (CVSS 10.0): mysql-mcp-server SSE mode skipped Host/Origin DNS-rebinding protection, bound 0.0.0.0 with no auth - unauthenticated SQL until 0.4.2. Anomity Research · Sep 21, 2026 · CVE-2026-59971 (CVSS 10.0, GHSA-rqfv-2mw9-78g2)](https://anomity.ai/blog/mysql-mcp-server-sse-dns-rebinding-unauth-sql-cve-2026-59971/) ## Structured data ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519", "description": "CVE-2026-46519 (CVSS 8.8): mcp-server-kubernetes enforces tool limits at tools/list, not tools/call, so any client can run kubectl_delete. Fix in v3.6.0.", "datePublished": "2026-06-11", "dateModified": "2026-06-11", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/prompt-injection.jpg", "width": 1200, "height": 630 }, "articleSection": "MCP Server Security", "url": "https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/", "keywords": "mcp-server-kubernetes access bypass, CVE-2026-46519, MCP, access control bypass, CVE-2026-46519, Kubernetes, runtime governance" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Am I affected by CVE-2026-46519?", "acceptedAnswer": { "@type": "Answer", "text": "You are exposed if you run any build of mcp-server-kubernetes prior to v3.6.0 with its HTTP endpoint reachable, even when you have set ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS to lock the server down. Those variables filter the tool list a client sees, but they do not stop a client that already knows a tool name from calling it. The fix landed in v3.6.0, which adds the missing enforcement at the execution layer. The first step is knowing where this server runs across your fleet and which version each instance is on, which needs an inventory of the AI artifact layer." } }, { "@type": "Question", "name": "What does the vulnerability allow an attacker to do?", "acceptedAnswer": { "@type": "Answer", "text": "CVE-2026-46519 carries a CVSS score of 8.8. An attacker or a misconfigured agent with network access to the HTTP endpoint can invoke any tool the server implements regardless of the configured restriction mode, including kubectl_delete, exec_in_pod, kubectl_generic, and node_management. Because development and staging deployments commonly run the server with cluster-admin privileges, the bypass can hand over full control of the cluster: deleting workloads, executing commands inside running pods, and cordoning or modifying nodes. A read-only configuration provides no actual protection against a client that calls the destructive tool by name." } }, { "@type": "Question", "name": "Why did the restriction modes fail to block the calls?", "acceptedAnswer": { "@type": "Answer", "text": "The server applies ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, and ALLOWED_TOOLS correctly at the tool discovery layer - the tools/list handler builds the advertised list with the restrictions applied. The enforcement is missing at the execution layer: the tools/call handler runs whatever tool name it receives without rechecking it against the configured mode. That creates a disconnect between advertised and actual capability. A client never has to read the list; it can call a tool directly. Filtering which tools are listed is not the same as governing which tool calls are permitted to execute." } }, { "@type": "Question", "name": "How does Anomity help with CVE-2026-46519?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity inventories MCP servers across every managed endpoint and surfaces the version in use, so finding every mcp-server-kubernetes instance prior to v3.6.0 is one query rather than a fleet hunt. On agents that expose a hook, it evaluates each tool call against your policy and returns allow, deny, or log before the call runs, so a kubectl_delete or exec_in_pod invocation is checked at the execution boundary even when the server itself would not. Every install, version change, and decision lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "mcp-server-kubernetes Tool Restriction Bypass at Execution Layer - CVE-2026-46519", "item": "https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/" } ] } ```