CVE-2026-18618: Ml-metdata: bundled grpc 1.46.3 (2022) with published http/2 dos cves — directly reachable on listener
A flaw was found in ml-metadata. The statically-linked gRPC stack in ml-metadata is outdated, making it vulnerable to known HTTP/2 denial of service (DoS) issues. An in-cluster attacker, with network access to the MLMD pod, could exploit these vulnerabilities by sending specially crafted HTTP/2 requests. This could lead to a denial of service by crashing the MLMD pod, disrupting all pipeline runs in the affected namespace.
Other sources
Finding The statically-linked gRPC stack is pinned to v1.46.3 (2022) in the Bazel WORKSPACE file, predating multiple HTTP/2 DoS CVEs that are directly reachable on the network listener:
WORKSPACE:116-117 comgithubgrpcgrpc → gRPC 1.46.3 WORKSPACE:129-130 comgoogleprotobuf → protobuf 3.21.12 WORKSPACE:173-176 zlib → 1.3 The MLMD server is a network-facing gRPC listener (FIND-001: no auth), so gRPC-layer DoS CVEs are directly reachable from any pod that can open a TCP connection to :8080.
The Bazel WORKSPACE pins are content-addressed (sha256), so the issue is staleness, not mutability. Renovate is present (.github/renovate.json) but evidently not covering Bazel httparchive entries.
File: WORKSPACE:116-117,129-130,173-176 Repository: red-hat-data-services/ml-metadata Framework: ASVS V14.2.1; OWASP K8s K07 Vulnerable Components; OpenSSF Scorecard Vulnerabilities CWE: CWE-1395 / CWE-1104 CVSS v3.1: 7.5 (High) AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (inherits gRPC HTTP/2 DoS vectors)
RHOAI Mitigation The DSPO-deployed NetworkPolicy restricts who can reach MLMD port 8080 to only KFP v2 driver pods and DSP components. This limits the attack surface but does not eliminate it — a compromise of a KFP driver pod or DSP component could exploit these CVEs to crash the MLMD pod and disrupt all pipeline runs in the namespace.
Impact An in-cluster attacker who can reach the MLMD pod (within the NetworkPolicy allowlist) can crash or resource-exhaust the MLMD pod via known gRPC/HTTP2 frame-handling bugs, disrupting all pipeline runs in the namespace.
Context ml-metadata is planned for removal from the product (several months out). The stale dependency risk remains active until removal is complete.
Remediation Bump WORKSPACE pins: gRPC >= 1.62, protobuf >= 25.x, zlib >= 1.3.1. Extend Renovate configuration to cover Bazel httparchive entries.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Rely on the existing DSPO-deployed NetworkPolicy that restricts access to the MLMD port 8080 to only KFP v2 driver pods and DSP components, since the MLMD server is a network-facing gRPC listener without auth and the HTTP/2 DoS vectors are directly reachable from any pod that can open a TCP connection to :8080.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-18618?
The severity of CVE-2026-18618 is rated high with a score of 7.5.
What vulnerability does CVE-2026-18618 describe?
CVE-2026-18618 describes a denial of service vulnerability due to an outdated gRPC stack in ml-metadata.
How does CVE-2026-18618 impact system security?
CVE-2026-18618 allows an in-cluster attacker with network access to the MLMD pod to exploit the vulnerability and cause a denial of service.
How do I fix CVE-2026-18618?
To fix CVE-2026-18618, update ml-metadata to utilize a more recent and secure version of the gRPC stack.
Who is affected by CVE-2026-18618?
Users of ml-metadata with the vulnerable version of the gRPC stack, particularly those running in cluster environments, are affected by CVE-2026-18618.