CVE-2026-41992

What it actually does

GNU gzip can read outside the bounds of a global decompression buffer when LZW and LZH files are decompressed in sequence within the same gzip process. The root cause is shared global state reused across LZ77, LZW, and LZH decompression routines without proper reinitialization between input files. A crafted LZW file can poison this shared state, and a subsequent crafted LZH file can cause the LZH decoder to follow stale values and perform out-of-bounds reads. The expected impact is unauthorized disclosure of memory from the gzip process; code execution is not indicated by the provided details.

Why it matters to the business

Systems and workflows that automatically decompress untrusted archives may expose sensitive process memory if they invoke gzip once across multiple files. The risk is most relevant for Linux/Unix servers, build systems, malware sandboxes, email/file-ingestion gateways, backup workflows, and data-processing pipelines that handle externally supplied compressed files. Current exploitation likelihood appears low: EPSS is 0.00335 with no 30-day increase, there is no known CISA KEV listing, no ransomware association, and no mature public exploit is reported. However, gzip is widely deployed, so organizations should still patch through normal operating-system and package-management channels.

How an attack unfolds

An attacker prepares two malicious compressed inputs: first, a specially crafted LZW-compressed file designed to leave attacker-controlled or malformed values in gzip's shared global decompression array; second, a specially crafted LZH-compressed file that causes the LZH decoder to consume those stale values. The attacker must get both files processed by the same gzip -d invocation, with the LZW file handled before the LZH file. This could occur through a local command, a scripted batch-decompression workflow, or an automated file-processing service that passes multiple user-controlled files to gzip at once. When gzip processes the second file, the stale global state can cause out-of-bounds reads beyond the allocated buffer, potentially exposing memory from the gzip process through output, diagnostics, crash artifacts, or instrumentation logs.

How to fix it

Update GNU gzip to a vendor-supplied version that includes the upstream fix from commit 63dbf6b3b9e6e781df1a6a64e609b10e23969681. Where package-specific fixed versions are not available, apply the latest gzip security update from the operating-system or distribution vendor and confirm the package changelog references this vulnerability or the upstream fix. As interim mitigations, avoid decompressing untrusted LZW and LZH inputs in the same gzip invocation, process each archive in a fresh process, disable or reject legacy LZW/LZH formats where not required, and run decompression of untrusted files in a sandbox with minimal privileges, no secrets in the environment, restricted filesystem access, and crash/core-dump collection disabled unless needed for investigation.

How to confirm the fix worked

Confirm the installed gzip package is updated by checking the operating-system package version, vendor advisory, or changelog for the fix commit 63dbf6b3b9e6e781df1a6a64e609b10e23969681 or this vulnerability. Use `gzip --version` only as supporting evidence because distribution backports may keep the same upstream version string. Review automation and scripts for patterns that pass multiple untrusted files to one `gzip -d` process, especially mixed legacy LZW and LZH inputs. In a controlled test environment, a known proof-of-concept corpus or sanitizer-instrumented build can be used to verify that the crafted LZW-then-LZH sequence no longer produces out-of-bounds-read or global-buffer-overflow diagnostics.

Typical attack path

1. Identify a workflow that uses GNU gzip to decompress multiple files in a single process invocation.
2. Deliver or place a crafted LZW-compressed file and a crafted LZH-compressed file where the workflow will process them together.
3. Ensure the LZW file is decompressed before the LZH file in the same gzip -d command.
4. The LZW decompression stage poisons shared global state that is not reset between files.
5. The LZH decompression stage follows stale values from the shared array and performs an out-of-bounds read.
6. The attacker attempts to recover exposed process memory from decompression output, logs, crash dumps, sanitizer output, or other generated artifacts.

How to detect it

Retrospective detection should focus on evidence that gzip processed attacker-controlled LZW and LZH inputs together, followed by crashes, sanitizer findings, unusual output, or core dumps. Useful log sources include EDR process telemetry, Linux auditd or process accounting, shell history, CI/CD job logs, file-ingestion service logs, email/file gateway logs, application worker logs, syslog, systemd journal entries, kernel core-dump logs, and crash-reporting systems. Look for `gzip -d` invocations with multiple input files where a legacy LZW file such as `.Z` appears before an LZH file such as `.lzh` or `.lha`. Also search for memory-safety diagnostics referencing gzip, global-buffer-overflow, out-of-bounds reads, or LZH decompression. Absence of these artifacts does not prove non-exploitation because a successful out-of-bounds read may leave minimal evidence unless command-line auditing, crash logging, or sanitizer instrumentation was enabled.

• gzip -d
• gzip --decompress
• AddressSanitizer: global-buffer-overflow
• AddressSanitizer: out-of-bounds
• runtime error: index out of bounds
• global-buffer-overflow
• out-of-bounds read
• core dumped
• gzip core dumped
• Process: gzip
• comm="gzip"
• .lzh
• .lha
• .Z
• unlzh
• LZH
• LZW

What your security team should do

• Prioritize patching gzip on systems that automatically ingest or decompress untrusted archives, including file gateways, build workers, analysis sandboxes, CI/CD runners, data pipelines, and shared shell servers.
• Inventory scripts and services that run `gzip -d` or equivalent batch decompression against multiple input files, and change them to spawn a fresh process per untrusted archive where practical.
• Temporarily block or quarantine unexpected LZW and LZH file types from untrusted sources if those formats are not business-required.
• Run decompression services with least privilege, isolated temporary directories, restricted environment variables, and sandboxing controls to reduce the value of any leaked process memory.
• Enable process execution and crash telemetry for gzip on high-risk ingestion systems so suspicious multi-file decompression attempts and memory-safety failures can be investigated.
• Because there is no KEV listing, no known ransomware use, and low EPSS at this time, handle this as standard-priority patching unless the organization processes untrusted archives at scale.