CVE-2026-18618: ml-metadata gRPC HTTP/2 DoS Vulnerability

CVE-2026-18618 Overview

A flaw was discovered in ml-metadata (MLMD), the metadata store used by machine learning pipeline platforms such as Kubeflow. The statically-linked gRPC stack bundled with ml-metadata is outdated and inherits known HTTP/2 denial of service vulnerabilities. An attacker with in-cluster network access to the MLMD pod can send specially crafted HTTP/2 requests to crash the service. The resulting outage disrupts all pipeline runs in the affected namespace, breaking training, evaluation, and deployment workflows that depend on metadata tracking. The weakness is classified under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
An in-cluster attacker can crash the MLMD pod with crafted HTTP/2 traffic, halting every ML pipeline in the affected namespace.

Affected Products

Red Hat OpenShift AI distributions bundling ml-metadata
Kubeflow Pipelines deployments using the MLMD gRPC service
Any container image statically linking the outdated gRPC stack in ml-metadata

Discovery Timeline

2026-08-10 - CVE-2026-18618 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-18618

Vulnerability Analysis

The ml-metadata project exposes a gRPC API over HTTP/2 for storing and retrieving ML pipeline metadata such as artifacts, executions, and lineage. The service statically links its gRPC dependency at build time. Because that dependency has not been refreshed, ml-metadata carries known HTTP/2 protocol flaws that were already patched upstream in newer gRPC releases.

HTTP/2 flaws in this class, including Rapid Reset and MadeYouReset-style abuses, allow a client to force a server to allocate resources for streams that are cancelled or manipulated before completion. The server continues to spend CPU and memory on stream state, header decompression, and request dispatch. Sustained crafted traffic exhausts the pod's resource budget and terminates the process.

Because MLMD is a singleton dependency for pipeline orchestration, its termination cascades into every workflow that reads or writes metadata in the namespace.

Root Cause

The root cause is a supply chain issue: a statically-linked, out-of-date gRPC stack. The bundled library predates the fixes for HTTP/2 stream lifecycle abuses, and the resource management in that older code does not throttle or bound the impact of malicious stream churn, matching the CWE-770 pattern.

Attack Vector

Exploitation requires network reachability to the MLMD pod. In typical Kubeflow or OpenShift AI deployments, MLMD is exposed as an internal ClusterIP service reachable from other pods in the same namespace or cluster. An attacker who already has a foothold in a workload, a compromised notebook container, or lateral movement within the cluster network can open an HTTP/2 connection and issue crafted stream sequences that consume server resources until the pod crashes.

No authentication or user interaction is required against the MLMD endpoint itself. The impact is limited to availability; the vulnerability does not enable data disclosure or tampering.

Detection Methods for CVE-2026-18618

Indicators of Compromise

Repeated MLMD pod restarts or OOMKilled and CrashLoopBackOff states in the namespace hosting pipelines
Sudden spikes in HTTP/2 RST_STREAM frames or aborted streams toward the MLMD service port
Pipeline run failures with gRPC UNAVAILABLE or connection reset errors originating from MLMD clients

Detection Strategies

Correlate Kubernetes pod restart events for the MLMD deployment with network flow logs targeting its service port
Inspect gRPC server logs for bursts of short-lived streams, cancelled requests, or HTTP/2 protocol errors
Baseline normal request rates against the MLMD service and alert on deviations in stream open/close ratios

Monitoring Recommendations

Enable Kubernetes audit logs and container runtime telemetry on nodes hosting MLMD workloads
Ship gRPC and ingress logs to a centralized analytics platform with retention sufficient for post-incident review
Track pod-level CPU, memory, and goroutine counts for the MLMD container and alert on saturation events

How to Mitigate CVE-2026-18618

Immediate Actions Required

Apply vendor updates that rebuild ml-metadata against a patched gRPC release addressing the HTTP/2 DoS class
Restrict network access to the MLMD service using NetworkPolicies so only trusted pipeline components can reach it
Enforce authentication and mTLS in front of the MLMD gRPC endpoint where the platform supports it

Patch Information

Red Hat has published fixes and analysis in RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263. Additional detail is available in the Red Hat CVE analysis for CVE-2026-18618 and Bug #2510313. Update affected container images to the versions listed in those advisories.

Workarounds

Place a hardened HTTP/2-aware proxy such as Envoy in front of MLMD with strict stream and concurrency limits
Apply Kubernetes NetworkPolicy rules to allow only known pipeline controllers to open connections to MLMD
Set container resource limits and liveness probes so a crashed MLMD pod is restarted quickly while patches are staged

bash

# Example NetworkPolicy restricting MLMD ingress to trusted pipeline pods
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mlmd-restrict-ingress
  namespace: kubeflow
spec:
  podSelector:
    matchLabels:
      app: metadata-grpc-server
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          pipelines.kubeflow.org/trusted-client: "true"
    ports:
    - protocol: TCP
      port: 8080
EOF