Tetrak
GitHub ↗
Security · zlib

zlib's gz_write overflows a heap buffer after a failed write

zlib 1.2.11 through 1.3.2 contains a heap buffer overflow: after an underlying write() fails, gz_write() returns without resetting strm.next_in, and a later gz* write call derives a position from the stale pointer and writes past a heap allocation.

Advisory
CVE-2026-76844
Library
zlib, zlib on Debian
Published
Severity
7.4 out of 10, as published
Affected
zlib 1.2.11 through 1.3.2
Fixed in
see the upstream record
Reaches you
on a save path

What triggers it

A further gz* write call after the program's own write() failed (EPIPE on a blocking descriptor is enough; before 1.3.1.2 a gzclearerr() call must come between).

What sillybos does

Not reached by opening a file

Opening or reading a file never reaches this flaw, so a check before decoding has nothing to refuse. Listed so that nobody expects it to.

In zlib's gz file layer (gz_write), after the program's own write() fails. The trigger is an I/O failure, not anything a file carries, and nothing in the image stack calls that layer: libpng and libtiff use the raw deflate stream, Pillow's wheel references none of the gz write functions, and Python's zlib module has no gz API. Only a program that writes .gz files through zlib's own file functions is in the path.

Severity is the CVSS 3.1 base score worked out from the vector the upstream record gives (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H); the record gives no number. A sibling of CVE-2026-85091 in the same gz write layer; the check there that nothing in the image stack calls it carries over.

How to protect yourself

In general. Upgrade zlib to a version that has the fix; the upstream record names it.

Specifically. Not reached through an image: only a program's own gzwrite after a failed write; upgrade zlib.

The general advice applies to every row here.

Sources