CVE-2026-46519 is a high-severity authorization bypass vulnerability affecting mcp-server-kubernetes, a Model Context Protocol server used for Kubernetes cluster management. The flaw allows a client to directly execute restricted Kubernetes tools even when environment variables are configured to limit available operations.

This issue matters for DevOps teams, Kubernetes administrators, platform engineers, and security teams using AI agents or MCP-based tooling against Kubernetes clusters. If the MCP server is reachable and its Kubernetes service account has broad permissions, this vulnerability can create a serious cluster compromise path.

For more vulnerability coverage, visit the IT Knowledge Bases Advisory Center.

CVE-2026-46519 Summary

  • CVE ID: CVE-2026-46519
  • Component: mcp-server-kubernetes
  • Affected versions: Before 3.6.0
  • Fixed version: 3.6.0 and later
  • Severity: High
  • CVSS: 8.8
  • CWE: CWE-863, Incorrect Authorization
  • Primary risk: Restricted clients can execute Kubernetes tools that should be blocked

What Is CVE-2026-46519?

CVE-2026-46519 is an incorrect authorization vulnerability in mcp-server-kubernetes. The project exposes environment variables intended to restrict available Kubernetes operations, including ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, and ALLOWED_TOOLS.

In vulnerable versions, those controls were enforced at the tool discovery layer, meaning they changed what tools appeared in tools/list. However, the same authorization checks were not enforced at the execution layer, meaning a client could still call a restricted tool directly through tools/call.

Why This Kubernetes MCP Vulnerability Matters

The key issue is that tool visibility was treated like access control. That is not a safe security model. Hiding a tool from a client does not prevent that client from calling the tool if the backend execution path still accepts the request.

For Kubernetes environments, this is especially risky because MCP servers may be connected to AI agents, automation workflows, developer tools, or multi-client HTTP deployments. If one of those clients is compromised, misconfigured, or manipulated, it may be able to invoke Kubernetes actions outside the operator’s intended restrictions.

How the Access Control Bypass Works

The vulnerability exists because filtering was applied to tools/list but not consistently applied to tools/call. A restricted client may not see dangerous tools in discovery, but if it knows the tool name, it can request execution directly.

Examples of restricted tools that may be sensitive in a Kubernetes environment include:

  • kubectl_delete
  • exec_in_pod
  • kubectl_generic
  • node_management

This makes CVE-2026-46519 a server-side authorization problem, not a cosmetic interface bug. The enforcement must happen before execution, not only during tool discovery.

Potential Impact on Kubernetes Environments

The impact depends on the Kubernetes permissions assigned to the service account used by mcp-server-kubernetes. The vulnerability does not create new Kubernetes permissions by itself. However, it can let a client use permissions that the operator believed were blocked by MCP-level restrictions.

Possible impact includes:

  • Deleting pods or workloads.
  • Executing commands inside pods.
  • Modifying Kubernetes resources.
  • Running generic kubectl operations.
  • Accessing sensitive cluster information if the service account allows it.
  • Escalating operational damage in clusters where the MCP server runs with excessive RBAC permissions.

The worst-case scenario is an MCP server running with cluster-admin or similarly broad privileges. In that case, any authenticated client that can reach the MCP endpoint may have a much larger blast radius than expected.

Affected Versions

mcp-server-kubernetes versions before 3.6.0 are affected by CVE-2026-46519. The issue is fixed in version 3.6.0 and later.

Organizations using this project should update as soon as possible, especially if the MCP server is exposed over HTTP, SSE, or any multi-client transport.

How to Determine Exposure

  1. Identify whether mcp-server-kubernetes is deployed.
  2. Check the installed version and confirm whether it is earlier than 3.6.0.
  3. Review whether the server uses ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, or ALLOWED_TOOLS.
  4. Determine who or what can reach the MCP endpoint.
  5. Review the Kubernetes service account used by the MCP server.
  6. Check whether the service account has broad permissions such as cluster-admin.

Mitigation and Remediation

  • Upgrade to mcp-server-kubernetes 3.6.0 or later. This is the direct fix for CVE-2026-46519.
  • Restrict network access to MCP endpoints. Do not expose MCP servers publicly unless there is a strong, reviewed security reason.
  • Use strong authentication. Authentication does not replace per-tool authorization, but it reduces who can reach the endpoint.
  • Harden Kubernetes RBAC. The MCP server service account should only have the permissions required for the intended workflow.
  • Avoid cluster-admin for AI tooling. Broad service account permissions increase the damage if an MCP client is abused.
  • Review audit logs. Look for unexpected pod execution, delete operations, namespace changes, or generic Kubernetes API activity from the MCP server identity.

Detection and Monitoring Recommendations

Security teams should review Kubernetes audit logs and MCP server logs for unexpected tool execution. Pay close attention to actions that should have been blocked by configured MCP restrictions.

Investigate activity such as:

  • Unexpected kubectl delete activity.
  • Unexpected exec activity inside pods.
  • Resource changes from the MCP server service account.
  • Tool calls that do not match the intended allowlist.
  • Requests from unfamiliar clients or automation systems.

If the MCP server was reachable by multiple clients before patching, assume that tool restrictions may not have been reliable and review historical activity accordingly.

Frequently Asked Questions

What is CVE-2026-46519?

CVE-2026-46519 is an authorization bypass in mcp-server-kubernetes. Vulnerable versions hide restricted tools during discovery but fail to block direct execution through tools/call.

Does CVE-2026-46519 give attackers cluster-admin access?

Not by itself. The vulnerability does not create new Kubernetes permissions. The real impact depends on the Kubernetes permissions assigned to the MCP server service account.

Can Kubernetes RBAC reduce the risk?

Yes. Proper Kubernetes RBAC can limit the damage by restricting what the MCP server can do, even if MCP-level authorization controls are bypassed.

What version fixes CVE-2026-46519?

mcp-server-kubernetes version 3.6.0 fixes the issue by enforcing allowed-tool checks before tool execution.

External References

Internal Links

Key Takeaways

  • CVE-2026-46519 affects mcp-server-kubernetes versions before 3.6.0.
  • The flaw is an authorization bypass, not just a display or interface issue.
  • Restricted tools were hidden during discovery but could still be executed directly.
  • The impact depends heavily on the Kubernetes service account permissions.
  • Upgrade to version 3.6.0 or later and review Kubernetes RBAC immediately.
  • Do not treat MCP tool discovery as a security boundary.

Leave a Reply