MKP Kubernetes MCP Server Unauthenticated Memory Exhaustion via get_resource Tool

Technical Analysis

The vulnerability stems from a lack of authentication on the MCP HTTP endpoint (default port 8080) combined with missing input validation and memory bounding in the tool implementation. The get_resource tool passes attacker-supplied limitBytes and tailLines values into buildPodLogOpts(), which parses them as unbounded int64 values, and defaultGetPodLogs() then copies the full Kubernetes log stream into an in-memory bytes.Buffer via io.Copy with no application-side size cap. Because MKP's rate limiter only throttles request frequency, not per-request payload volume, one tools/call invocation against a pod with large accumulated logs can drive multi-gigabyte RSS growth (observed: >1 GiB RSS from a 128 MiB requested stream), crashing the server. This crosses the tool-boundary in that an AI agent (or any MCP client) invoking a seemingly benign log-retrieval tool becomes the vector for a classic unbounded-resource DoS against the underlying Kubernetes-integrated MCP infrastructure.

Affected Systems

MKP (Model Context Protocol server for Kubernetes); protocols: MCP

Detection Signatures

• tools/call requests to get_resource with abnormally large or absent limitBytes/tailLines values
• Sudden RSS/memory spikes correlated with MCP server pod-log requests
• Unauthenticated HTTP requests reaching MCP server default port 8080
• Absence of Authorization/Bearer headers on tools/call POST requests
• Repeated get_resource calls targeting pods with very large log history

Remediation Steps

1. 1

   Upgrade MKP

   Update to MKP version 0.4.1 or later, which fixes the unbounded log buffering and adds appropriate limits.

2. 2

   Restrict network exposure

   Do not expose the MKP MCP HTTP endpoint (port 8080) directly to untrusted networks; place it behind a firewall, VPN, or authenticating reverse proxy.

3. 3

   Enforce authentication

   Require authentication/authorization on all MCP tool endpoints, especially get_resource, before allowing pod log access.

4. 4

   Apply resource limits

   Set container/process memory limits (e.g., Kubernetes resource limits, cgroups) on the MKP server to bound the impact of any single oversized allocation.

5. 5

   Validate tool parameters

   Add server-side bounds checking on limitBytes and tailLines to reject or cap unreasonably large values regardless of client input.

6. 6

   Monitor resource usage

   Add memory/RSS monitoring and alerting on MCP server processes to detect abnormal growth indicative of exploitation attempts.