<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T20:54:05.009197+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-50125</id>
    <title>fkie_cve-2026-50125</title>
    <updated>2026-09-28T20:54:05.035699+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>MKP is a Model Context Protocol server for Kubernetes. Prior to 0.4.1, cmd/server/main.go exposes the default HTTP endpoint and pkg/mcp/server.go registers the unauthenticated get_resource tool, which accepts attacker-controlled limitBytes and tailLines values for the pods logs subresource. buildPodLogOpts() in pkg/k8s/subresource.go parses those values as unbounded int64 parameters, and defaultGetPodLogs() copies the returned Kubernetes log stream through io.Copy into an in-memory bytes.Buffer without an application-side cap. A remote attacker who can reach the default port 8080 MCP endpoint and select a pod with sufficiently large accumulated logs can send one tools/call request that causes large allocations and additional response copies, while the request-frequency limiter does not constrain per-request volume. This can exhaust process memory, terminate the MKP server, and deny the MCP service; observed testing showed more than one GiB of RSS growth while handling a 128 MiB requested stream. This issue is fixed in version 0.4.1.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-50125"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-qw5r-ppcg-f8rj</id>
    <title>GHSA-qw5r-ppcg-f8rj — MKP: Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion</title>
    <updated>2026-09-28T20:54:05.035791+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/StacklokLabs/mkp</p>
<p>## Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion</p>
<p>### Summary</p>
<p>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`.</p>
<p>### Details</p>
<p>The vulnerability exists in `pkg/k8s/subresource.go` in the `buildPodLogOpts()` and `defaultGetPodLogs()` functions.</p>
<p>**Source — unbounded parameter parsing (`pkg/k8s/subresource.go:171–181`):**</p>
<p>```go
// 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 = &amp;b  // no upper-bound check
    }
}
if tailLines, ok := parameters["tailLines"]; ok {
    if lines, err := strconv.ParseInt(tailLines, 1…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-qw5r-ppcg-f8rj"/>
  </entry>
</feed>
