Gzip 1.15 fixes bugs present since its inception, including an LZH buffer overflow
Gzip 1.15, released September 20, 2026, ships 119 commits of fixes including a buffer overflow and uninitialized memory access present since the early 1990s. Update gzip and treat archive decompression as untrusted input.
September 20, 2026. Jim Meyering announces gzip 1.15, a stable release. April 2025. The previous version, 1.14, had shipped seventeen months earlier. 1992. The project is born, and several of the bugs fixed today were already in the code. Why it matters: the most ubiquitous compression tool in the Unix world carried, for more than three decades, a buffer overflow in LZH decompression and an uninitialized memory access on malformed input.
gzip is one of the oldest pieces of software still in everyday use. Created in 1992 by Jean-loup Gailly and Mark Adler as a free replacement for the compress utility, its name is a contraction of GNU zip. Its .gz files, its .tar.gz pairing with tar, and the gzip HTTP content-encoding are now woven so deeply into computing that most people never notice them — which is exactly why a bug living there since 1992 matters: it has been running, unpatched, at planetary scale for thirty-four years.
Bugs present since the beginning
The gzip 1.15 release notes are a lesson in software humility. They list fixes, each followed by the same note: “bug present since the beginning.” Some are curiosities; others are silent security defects.
Among the curiosities, gzip could remove the wrong file if another process simultaneously renamed the destination’s parent directory — a blind race condition fixed after decades. gzip -d also rejected certain PKZIP signatures, local headers, and data descriptors that legitimately appear in well-formed streamed zip files. And the diagnostics did not quote file names containing unusual characters, a detail that complicates life for anyone automating on exotic names.
But two fixes are security in the strictest sense. The first: an uninitialized memory access on some malformed inputs. The second, and most serious: a buffer overflow when decompressing an .lzh file after a .Z file. Two memory-safety defects in a tool invoked without a second thought millions of times a day.
The buffer overflow in LZH decompression
The LZH format is a legacy of LHarc, an archive format popular in the late 1980s. gzip can decompress it in addition to its native .gz format and the .Z format of the old compress program. It is precisely in this compatibility path, less tested than the core product, that the buffer overflow lived.
The exploitation scenario is demanding but real: an .lzh file must be decompressed immediately after a .Z file in the same session. State left behind by the first format corrupts the handling of the second, and a carefully crafted .lzh file can write past a buffer. In practice, that means a user decompressing a malicious archive — received by email, downloaded, or dropped into a processing pipeline — exposes the process to an out-of-bounds write.
Two further fixes hit the same format: .lzh output could be corrupted when an internal bit buffer was not properly cleared, or when one .lzh file followed another whose decoding table persisted. In other words, gzip’s LZH support was both buggy and fragile from the start, and nobody noticed because almost nobody seriously tests LHarc in 2026.
The .Z format itself is a relic: it belongs to the old compress program, whose LZW algorithm was tangled in patent disputes in the early 1990s — one reason gzip was built around DEFLATE instead. That gzip still ships decompression for .Z and .lzh is a compatibility commitment to decades-old archives, and it is in these rarely-exercised paths that the memory-safety bugs hid.
119 commits, five people, seventy-five weeks
The announcement gives the exact measure of the effort: 119 commits by 5 people over 75 weeks. The contributors are Bruno Haible (2 commits), Collin Funk (2), Jim Meyering (24), Mark Adler (3), and Paul Eggert (88). Eggert alone carries three-quarters of the work.
That is the reality of maintaining GNU’s foundational tools. gzip is present on virtually every Linux distribution, in containers, servers, routers, and embedded systems. It compresses logs, backups, and package archives. And yet its maintenance rests on five people, one of whom does most of the fixing, over more than a year and a half.
The contrast is instructive. A vendor announces a security patch with fanfare; a gzip maintainer ships a stable release that silently eliminates a thirty-year-old buffer overflow, with no CVE, no advisory, no mediatized urgency. The risk is real; the discretion is total.
Why decompression remains an attack surface
The gzip 1.15 fix illustrates a rule security teams know but rarely apply to the end: decompressing an archive is executing untrusted code. Compression formats are parsers, and parsers are attack surfaces. gzip’s LZH overflow belongs to the same family as the flaws routinely found in zlib, libarchive, 7-Zip, and the decompressors embedded in browsers.
The practical consequence goes beyond updating gzip itself. Any pipeline that decompresses data from an external source — a user upload, a downloaded build artifact, a restored backup — potentially runs a vulnerable parser on third-party-controlled input. The defense is isolation of those steps (a dedicated container, an unprivileged user, resource limits) and systematic updating of every decompressor, not just the most visible one.
For administrators, the update is simple but not to be deferred: gzip 1.15 lands in distribution repositories in the days or weeks that follow. Servers that decompress internet-sourced archives should be prioritized, as should machines that process email attachments.
The track record backs the concern. In 2022, zlib — the library that sits beneath gzip’s own format — patched CVE-2022-37434, a heap-based buffer overflow in inflate reachable through malformed compressed data. In late 2024, 7-Zip fixed CVE-2024-11477, an integer overflow in its Zstandard decompressor enabling remote code execution through a crafted archive. Neither is exotic: they are the same decompressors that run whenever an operating system, a package manager, or a user unzips, unpacks, or extracts a file under the assumption that compression is safe.
What changes beyond the bugs
Two behavior changes accompany the fixes. First, gzip no longer assumes the C locale by default: it now follows the locale environment variable for how it quotes file names. A minor change for the user, but revealing of attention paid to non-English environments.
Second, the release drops support for historical platforms: FreeBSD 4.11, HP-UX 11.00, Minix 3.1.8, and Windows 8.1 via MinGW without UCRT. Trimming the support matrix means less code to maintain and test — a maintainer’s choice consistent with a project carried by five people.
Both changes point the same way: gzip is refocusing on what matters — the reliability of the format and of the platforms still in use — rather than on museum-grade compatibility.
Verdict
If you run Linux servers, update gzip as soon as 1.15 reaches your repositories, prioritizing machines that decompress external archives — mail servers, build pipelines, restore points. If you write code that handles archives, treat decompression as an untrusted input boundary: isolate it, limit its resources, and never trust a file just because it is “only compressed.” If you depend on a foundational GNU tool, remember that its maintenance rests on a handful of people, often volunteers: funding or contributing to these projects is a security measure in its own right.