GNU gzip

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 2 Last 12 months Out-of-bounds write 40 % Out-of-bounds read 25 % Input validation 20 % Denial of service 15 % Latest advisories Loading the feed Overview gzip is the reference DEFLATE implementation and ships in the base install of essentially every Linux system. Alongside DEFLATE it still carries decompressors for LZH, pack and compress, formats almost nobody produces any more and every gzip binary will still happily parse. CVE-2026-41992 is the reference point, a global buffer overflow in exactly that LZH path. There is no project security channel: the GNU-wide policy asks you to email maintainers privately, and the 2026 findings were coordinated through a national CERT instead. Nothing is paid for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope There is no gzip-specific security policy. The GNU-wide policy is the only written guidance and it accepts a private report by email to the maintainers, with [email protected] as a fallback. Nothing narrower than the gzip tree is carved out, because nothing is carved out at all The DEFLATE decompressor and compressor, the code path that runs on effectively every Linux system The legacy decoders compiled into every build: LZH, pack and compress, along with the format detection that decides which of them handles a file gzip header parsing in full: the stored filename field, the comment field, the extra fields and the flags that say which are present The trailer, including CRC and size checking and what gzip does when they disagree Command-line handling and filesystem behaviour: the suffix logic, recursive mode, the output path gzip derives from an input name, and permission and ownership handling on the file it writes The zgrep , zless , zdiff , zmore , zcat and zforce wrapper scripts shipped with gzip, which take filenames from the caller and hand them to other tools gzexe and the self-extracting shell scripts it generates Out of scope Anything posted to [email protected] or another public list, since that is disclosure rather than a report Other implementations of the gzip format. zlib, libdeflate, Go's compress/gzip and the rest are separate projects with their own reporting Distribution packaging and distro-specific patches rather than upstream gzip Compression-ratio denial of service inherent to DEFLATE. A file that expands enormously is a property of the format rather than a gzip defect Behaviour an administrator chose, such as pointing recursive mode at a directory tree they do not control Most-valued findings Memory corruption in the legacy decoders above all. CVE-2026-41992 was a global buffer overflow in LZH decompression, and those decoders are barely exercised, rarely fuzzed and compiled into every gzip on earth Out-of-bounds reads or writes in header field parsing, where the filename and comment fields are attacker-controlled strings of attacker-chosen length Path handling driven by the stored filename in the header, where decompression writes somewhere the user did not intend Argument and filename handling in the z* wrapper scripts, where a crafted name reaches a shell or another tool with the caller's privileges Anything reachable from a file arriving over the network, since gzip is routinely run on downloads, logs and backups from elsewhere Defects in the DEFLATE path itself, which are rarer and correspondingly more valuable given how much runs through it Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. There is no gzip security address. The GNU-wide policy is the only written guidance: email the maintainers individually and privately, with [email protected] as the last resort Do not use [email protected] for a vulnerability. It is a public list and posting there is disclosure There is no SECURITY.md in the gzip tree and no security section on the project page, so expect to establish the private channel yourself rather than follow a documented one A national CERT is a realistic coordinator here. CERT-PL acted as CNA for both 2026 gzip CVEs and drove the disclosure, which the project has no process to do Attach the compressed file that reproduces it and name the format, since the legacy decoders behave nothing like the DEFLATE path Nothing is paid for a report. There is no reward to negotiate and no reward terms to accept Disclosure There is no published timeline and no project process to hold one. The 2026 pattern is the guide: CERT-PL took the reports, assigned the CVEs, coordinated with distributions and published on its own schedule with the reporters credited. Expect coordination to be driven by whoever you route through rather than by the project, and expect distributions to be the ones actually shipping the fix to users. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability