Heap buffer overflow in zlib non-blocking gzwrite() handling
CVE-2026-85091 is a heap buffer overflow affecting zlib versions 1.3.1.2 through 1.3.2. During non-blocking gzwrite() operations, a write stall can leave stale external buffer pointers. A subsequent call to gzprintf() or gzvprintf() can reach gz_vacate(), where an unchecked memmove() writes beyond the internal input buffer boundary. The resulting heap corruption can cause denial of service or potentially arbitrary code execution. Exposure depends on an application using the affected write sequence; merely linking against zlib does not establish exploitability.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can corrupt heap memory, crash the affected application, and potentially execute arbitrary code in its security context. Integrity and availability can be severely affected. Arbitrary code execution is a potential consequence, not an established outcome for every application using the vulnerable library.
If you can’t patch tonight, do this now.
Until patched, avoid or disable affected non-blocking gzwrite() workflows, particularly sequences that call gzprintf() or gzvprintf() after a write stall. Restrict untrusted access to application features that can trigger this sequence. No vendor-supported temporary workaround is specified.
Patch, then assume compromise.
Upgrade to zlib 1.4 or a distribution-supported package containing the backported fix. Identified fixed packages include Alpine zlib 1.3.2-r1 or later; Debian 13 zlib 1:1.3.dfsg+really1.3.1-1+deb13u1 or later; Ubuntu 26.10 zlib 1:1.3.dfsg+really1.3.2-3ubuntu1.1; Ubuntu 26.04 LTS zlib 1:1.3.dfsg+really1.3.1-1ubuntu3.2; and Ubuntu 24.04 LTS zlib 1:1.3.dfsg-3.1ubuntu2.3. Verify the actual library copy used by each application, including bundled and statically linked copies. Rebuild affected application binaries and container images where necessary, and restart processes to load the repaired code.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
18 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.