GHSA-qw5r-ppcg-f8rj

Unbounded Pod Log Read via Attacker-Controlled limitBytes/tailLines Causes Memory Exhaustion

Summary

The MKP (Model Context Protocol for Kubernetes) server exposes a get_resource MCP tool that proxies Kubernetes pod log requests. User-supplied limitBytes and tailLines parameters are parsed as unbounded int64 values and forwarded directly to the Kubernetes API. The server then reads the entire returned log stream into an in-memory bytes.Buffer using io.Copy without any application-side size cap. A remote unauthenticated attacker can exploit this to exhaust the MKP server's memory by sending a single crafted tools/call request, leading to process termination (OOM kill) and denial of service. Dynamic reproduction confirmed the MKP process RSS grew from 25.8 MB to 1,179.3 MB (+1,153.4 MB) while handling one request with limitBytes=134217728.

Details

The vulnerability exists in pkg/k8s/subresource.go in the buildPodLogOpts() and defaultGetPodLogs() functions.

Source — unbounded parameter parsing (pkg/k8s/subresource.go:171–181):

// pkg/k8s/subresource.go
defaultLimitBytes := int64(32 * 1024) // 32 KB — only used when parameters map is nil
...
if limitBytes, ok := parameters["limitBytes"]; ok {
    if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil {
        podLogOpts.LimitBytes = &b  // no upper-bound check
    }
}
if tailLines, ok := parameters["tailLines"]; ok {
    if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil {
        podLogOpts.TailLines = &lines  // no upper-bound check
    }
}

When the parameters map is non-nil (always true for attacker-supplied input), buildPodLogOpts() is called at pkg/k8s/subresource.go:94–96 and overwrites the 32 KB default entirely. The attacker can therefore supply any positive int64 value (up to 2147483647 or 9223372036854775807) as limitBytes.

Sink — unbounded in-memory copy (pkg/k8s/subresource.go:114–115):

buf :=...