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.

gzip integer overflow

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.

inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic

Last updated 11 July 2025

An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.

External References:

https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7

Upstream patch:

https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb

CVE assignment:

http://seclists.org/oss-sec/2016/q4/602

Last updated 14 January 2026

A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.

Last updated 13 November 2024

AMD. A buffer overflow issue was addressed with improved memory handling.

zlib versions up to and including 1.3.1.2 include a global buffer overflow in the untgz utility located under contrib/untgz. The vulnerability is limited to the standalone demonstration utility and does not affect the core zlib compression library. The flaw occurs when a user executes the untgz command with an excessively long archive name supplied via the command line, leading to an out-of-bounds write in a fixed-size global buffer.

zlib 1.2 and later versions allows remote attackers to cause a denial of service (crash) via a crafted compressed stream with an incomplete code description of a length greater than 1, which leads to a buffer overflow, as demonstrated using a crafted PNG file.

zlib before 1.3.2 allows CPU consumption via crc32combine64 and crc32combinegen64 because x2nmodp can do right shifts within a loop that has no termination condition.

Buffer overflow in the gzprintf function in zlib 1.1.4, when zlib is compiled without vsnprintf or when long inputs are truncated using vsnprintf, allows attackers to cause a denial of service or possibly execute arbitrary code.

zlib versions up to and including 1.3.1.2 contain a global buffer overflow in the untgz utility. The TGZfname() function copies an attacker-supplied archive name from argv[] into a fixed-size 1024-byte static global buffer using an unbounded strcpy() call without length validation. Supplying an archive name longer than 1024 bytes results in an out-of-bounds write that can lead to memory corruption, denial of service, and potentially code execution depending on compiler, build flags, architecture, and memory layout. The overflow occurs prior to any archive parsing or validation.

On Tuesday 2026-02-17 22:21, Simon Josefsson wrote: Sam James <sam () gentoo org> writes: ZLB-01-001 WP2: Heap Buffer Overflow via Legacy gzprintf Implementation (High) That vulnerability seems to require that zlib was built with -DNOvsnprintf -DNOsnprintf, targetting a system lacking 'snprintf'.

Does anyone know of a real-world environment using that configuration? Does Borland C++ 1.01 for DOS count?

On 1/6/26 09:31, Alan Coopersmith wrote: I didn't see any mention of this in https://github.com/madler/zlib so I filed https://github.com/madler/zlib/issues/1142 .

Note once again, this is in a utility in the contrib directory, not the main zlib library itself.  (And 1.3.1.2 is not an actual release, but a git tag being used for other purposes - see https://github.com/madler/zlib/discussions/1128 .) The bug has been closed now that untgz has been removed from the zlib contrib directory so that people stop harassing the zlib maintainers about code they don't maintain:

https://github.com/madler/zlib/commit/1a40058a92d525aa49a6eac698cfde500fc9b92f

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

The decompression algorithm in zlib 1.1.3 and earlier, as used in many different utilities and packages, causes inflateEnd to release certain memory more than once (a "double free"), which may allow local and remote attackers to execute arbitrary code via a block of malformed compression data.

The error handling in the (1) inflate and (2) inflateBack functions in ZLib compression library 1.2.x allows local users to cause a denial of service (application crash).

inftrees.h in zlib 1.2.2 allows remote attackers to cause a denial of service (application crash) via an invalid file that causes a large dynamic tree to be produced.