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.

Race condition in pigz before 2.2.5 uses permissions derived from the umask when compressing a file before setting that file's permissions to match those of the original file, which might allow local users to bypass intended access permissions while compression is occurring.

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

I'm trying to implement some sort of container image scanning to our CI pipelines. Trivy seems perfect, but it's very sensitive. One of our images is coming up with a critical for zlib that doesn't sound that critical, and which I assume is coming up because it's using a base image based on Debian Bookworm (it's an official Microsoft container registry image, so not something I can update). Docker Scout and AWS Inspector don't show any criticals, and only 1 high vs the 15 Trivy found.

Does anyone else use Trivy, and do you have these issues? I don't really want to put this in the pipeline and then have everyone ignore the results because of false positives. Should I just go with sending our SBOM to Inspector or something?

A vulnerability exists in the inftrees.c component of the zlib library, which is bundled within the PointCloudLibrary (PCL). This issue may allow context-dependent attackers to cause undefined behavior by exploiting improper pointer arithmetic.

Since version 1.14.0, PCL by default uses a zlib installation from the system, unless the user sets WITHSYSTEMZLIB=FALSE. So this potential vulnerability is only relevant if the PCL version is older than 1.14.0 or the user specifically requests to not use the system zlib.

Daniel Stenberg <daniel () haxx se> [2025-02-05 09:21]: [...] This problem can only trigger when using a run-time zlib version 1.2.0.3 or older. zlib 1.2.0.4 was relased on August 10, 2003. This means zlib versions that do not trigger this problem have been available and used for more than twenty-one years already. A zlib version 1.2.0.3 or earlier still in use is vulnerable to a wide range of security problems and a user using this is already in a spectacularly bad position.

libcurl featured code that at run-time takes a different code path for zlib versions before 1.0.2.4 because of lack of functionality in those old versions, and this rarely used piece of code contained the vulnerable code path. I assume this last version should have been 1.2.0.4 as before and not 1.0.2.4?

[...] SOLUTION ------------

Starting in version 8.12.0, libcurl no longer supports zlib < 1.2.0.4. Using such a version will now instead cause a run-time error.

- Fixed-in: https://github.com/curl/curl/commit/76f83f0db23846e254d940ec7 [...]

Looking at the patch it seems the version check is using a string comparison instead of a proper numeric one on the version tuple (major, minor, revision, subrevison):

if(strcmp(v, "1.2.0.4") >= 0) {

Which, whilst I doubt we'll see such a zlib version any time soon if ever (though zlib-ng compat might get there a lot faster), would give an incorrect result for e.g. version "1.10.0.0".

- Fay

gzip integer overflow =====================

Project curl Security Advisory, February 5th 2025 - Permalink

VULNERABILITY -------------

When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the CURLOPTACCEPTENCODING option, using zlib 1.2.0.3 or older, an attacker-controlled integer overflow would make libcurl perform a buffer overflow.

INFO ----

This problem can only trigger when using a run-time zlib version 1.2.0.3 or older. zlib 1.2.0.4 was relased on August 10, 2003. This means zlib versions that do not trigger this problem have been available and used for more than twenty-one years already. A zlib version 1.2.0.3 or earlier still in use is vulnerable to a wide range of security problems and a user using this is already in a spectacularly bad position.

libcurl featured code that at run-time takes a different code path for zlib versions before 1.0.2.4 because of lack of functionality in those old versions, and this rarely used piece of code contained the vulnerable code path.

This bug is considered a C mistake. It is likely to have been avoided had we not been using C.

This flaw also affects the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-0725 to this issue.

CWE-680: Integer Overflow to Buffer Overflow

Severity: Low

While the impact of this problem is potentially huge, we struggled with setting a severity combined with the knowledge that a user vulnerable to this is using an over twenty years old and vulnerable zlib and has practially "given up" all security. If there actually exist users vulnerable to this flaw in the world, they most likely already have worse problems than this to deal with.

AFFECTED VERSIONS -----------------

- Affected versions: curl 7.10.5 to and including 8.11.1 - Not affected versions: curl < 7.10.5 and >= 8.12.0 - Introduced-in: https://github.com/curl/curl/commit/019c4088cfcca0d2b7c5cc4f

libcurl is used by many applications, but not always advertised as such!

SOLUTION ------------

Starting in version 8.12.0, libcurl no longer supports zlib < 1.2.0.4. Using such a version will now instead cause a run-time error.

- Fixed-in: https://github.com/curl/curl/commit/76f83f0db23846e254d940ec7

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl and libcurl to version 8.12.0

B - Apply the patch to your version and rebuild

C - Use a modern zlib

D - Avoid using the CURLOPTACCEPTENCODING option

TIMELINE ---------

This issue was reported to the curl project on January 23, 2025. We contacted distros@openwall on January 28, 2025.

curl 8.12.0 was released on February 5 2025 around 08:00 UTC, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: z2 - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se

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.

Multiple directory traversal vulnerabilities in pigz 2.3.1 allow remote attackers to write to arbitrary files via a (1) full pathname or (2) .. (dot dot) in an archive.

CVE-2023-45853 was published last week for:

MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip464 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product.

where "long" means "longer than can be stored in the 16-bit length value used for the length of these fields".

minizip is part of the contrib directory in zlib, which doesn't seem to be built by default as far as I can tell, yet NVD has assigned a CVSS of 9.8 to make CVE scanners scream at full volume, while Red Hat went with a CVSS of 5.3 instead:

https://access.redhat.com/security/cve/CVE-2023-45853#cve-cvss-v3

A fix has been checked into the upstream git repo: https://github.com/madler/zlib/pull/843 but a release has not yet been made including it.

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