CVE-2026-76844 is a high severity (7.4) heap buffer overflow in zlib's gzwrite code. After a failed write, gz_write leaves a stale pointer, and a later gz write call can write past a heap allocation. The record names zlib 1.2.11 through 1.3.2. Confirm the fixed release in zlib's repository before you update.
What's affected
The record says zlib 1.2.11 through 1.3.2 contains the bug. It describes the trigger as any write() failure, including EPIPE on a blocking descriptor, and says versions before 1.3.1.2 also need a gzclearerr() call after the failed write.
Only code that uses the gz file API for writing is in scope, such as gzwrite and related calls. Programs that use zlib only for deflate or inflate in memory do not reach this path, going by the record.
The record links a fix commit in the zlib repository. We could not read a release note that names a fixed version, so we are not stating one. Check the zlib project and your distribution's security tracker.
Where sources differ. A VulnCheck advisory linked from the record lists the same bug as zlib 1.3.1.2 through 1.3.2, names the function gz_vacate, rates it 8.3 (CVSS 4.0) and uses a different CVE identifier, CVE-2026-85091. It describes the trigger as gzprintf or gzvprintf after a write stall. The record says 1.2.11 through 1.3.2, 7.4 High, and describes gz_write. The two disagree on the lower version bound, the score and the call path. Until the zlib project settles it, treat every zlib from 1.2.11 to 1.3.2 that you use for gz writes as in scope.
How to check if you're exposed
Find zlib on your systems, then find which software uses its gz API.
python3 -c "import zlib; print(zlib.ZLIB_VERSION)"
dpkg -l zlib1g
rpm -q zlib
apk info zlib
brew list --versions zlib
Those cover Python's build, Debian and Ubuntu, RPM systems, Alpine and Homebrew. Distribution packages often carry backported fixes under the same version number, so check the vendor's security tracker for the CVE as well as the version.
For your own code, search for calls to gzopen, gzwrite, gzprintf and gzputs. Statically linked and vendored copies of zlib will not show up in package managers, so look at build manifests and container images too. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- List every product and image that bundles or links zlib, including vendored copies inside larger projects.
- Find which of them write gzip files through the gz API. Those are the first to patch.
- Update to the zlib release the project names as fixed, or to your distribution's patched package. Check the repository commit referenced in the record if no release note is clear yet.
- Rebuild and redeploy anything that links zlib statically.
- Where a write can fail, such as a closed pipe, make sure error handling stops the stream instead of continuing to write.
Why it matters
The record's cause is a state bug. After an underlying write() fails, gz_write returns without resetting strm.next_in, leaving it pointed at the caller's buffer. A later gz write call derives a position from that stale pointer and writes beyond a heap allocation. That is an out of bounds write, filed under CWE-787.
The unusual part is how ordinary the trigger is. Any failed write counts, including a broken pipe, so an attacker who can influence when a write fails and what the program writes next may get further than a pure input bug would allow. The record's vector is network based with high attack complexity, and the record does not mark it as a CISA KEV entry. zlib sits under so many products that the fix is really a supply chain task, which is why an inventory comes first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect every program that uses zlib?
No. By the record it needs the gz file write path and a failed write. Programs that only compress or decompress in memory do not use that code.
Why do the record and the VulnCheck advisory differ?
They give different version ranges, scores and CVE identifiers for what looks like the same bug. Check the zlib project for the authoritative range.
Sources
Last reviewed: 18 October 2026.
