Gzip 1.15 fixes a wrong-file deletion race

Gzip 1.15 was released on September 20, 2026, and it fixes a bug that could make gzip delete the wrong file. Jim Meyering announced the release on the GNU info-gnu mailing list. Most of the bugs it fixes have been in gzip since the beginning, which means scripts have been running on top of them for decades.

Gzip is the compression program behind the .gz files that ship with almost every Linux and Unix system. It is wired into package managers, backup jobs and log rotation. A defect in it reaches far more machines than its low profile suggests.

The release carries 119 commits written over 75 weeks. Paul Eggert contributed 88 of them and Meyering 24, with smaller sets from Mark Adler, Bruno Haible and Collin Funk. The previous release, gzip 1.14, came out in April 2025 according to Phoronix.

What the deletion bug did

Gzip normally compresses a file and then removes the original. Working out which file to remove is where this bug lived.

The announcement states the fix plainly: "gzip no longer can mistakenly remove the wrong file if some other process simultaneously renames a gzip destination's ancestor." An ancestor here is any directory above the target file.

So the danger appears when two things happen at once. Gzip is partway through its work, and another process renames a folder in the path. Gzip then resolves the path again and can land on a different file than the one it started with.

This is a race condition, meaning the outcome depends on the timing of two separate programs. It needs that timing to line up, so it is rare. On a busy server running automated jobs, rare is not the same as never.

A second locking problem is also fixed. Synchronization could fail on systems that support the O_PATH or O_SEARCH file flags. That one is newer than the rest: it arrived in gzip 1.7.

Three corruption fixes in .lzh decoding

Gzip can still read .lzh files, an older compression format that was widely used in Japan. Three of the fixes are in that decoder.

One is a memory-safety fix. The announcement reports "a buffer overflow has been fixed when decompressing an .lzh file after decompressing a .Z file." A buffer overflow means the program writes past the end of the memory it reserved.

The other two produce wrong output rather than a crash. Decompressing one .lzh file after another could corrupt the result, because the previous file's decoding table was still in place. Output could also be corrupted when an internal bit buffer was not cleared properly.

Separately, the release fixes "a use of uninitialized memory on some malformed inputs." That is memory the program reads before anything has been written into it.

The announcement lists no CVE identifiers for any of these.

What else changed

Some changes alter behavior rather than fix a defect, and a few old platforms were dropped.

Change	What it means
Locale handling	Gzip follows the locale in your environment instead of assuming the C locale
Empty-file ratio	An empty file now reports -Inf% compression instead of 0.0%
znew -P	The option is ignored now, and prints a warning
Diagnostics	File names with unusual characters are quoted in messages
PKZIP streams	gzip -d accepts PKZIP signatures, local headers and data descriptors
Dropped platforms	FreeBSD 4.11 and earlier, HP-UX 11.00, Minix 3.1.8, Windows 8.1 via MinGW without UCRT

Temporary file races in the gzexe, zdiff and znew helper scripts were fixed as well.

What this means for developers

Treat this as a security update even though no CVE is attached. Two of the fixes are memory-safety bugs in the decoder. If any service you run feeds attacker-supplied archives to gzip, that decoder is reachable from outside, and it should be near the front of your patch queue. Rustls made the same point recently when it fixed a TLS 1.3 flaw open since 2024: age is not evidence that a bug is harmless.

Check your scripts for two specific things before upgrading. If anything parses gzip's compression-ratio output, the empty-file case now prints -Inf% and a parser expecting a plain number will break. If anything depends on gzip sorting or reporting file names the same way everywhere, the locale change can shift that result between machines.

The deletion race is worth a look if you run gzip where directories get renamed underneath it. Deployment scripts that swap a release folder into place are the common shape of that. The window is small, but the cost of losing the wrong file is not.

Finally, check the dropped platforms before you upgrade a build image. If you still compile for HP-UX 11.00 or for Windows 8.1 through MinGW without UCRT, gzip 1.15 is where that path ends.