CVE-2026-41991: GNU gzip gzexe Insecure Temporary File Vulnerability

Technical summary

CVE-2026-41991 is a TOCTOU (time-of-check to time-of-use) vulnerability in gzexe stemming from insecure temporary file creation. The gzexe utility normally relies on mktemp for secure temporary file generation. When mktemp is unavailable, it falls back to a predictable naming scheme based solely on the process ID—a value an attacker can enumerate or predict. The temporary file is created without checking for pre-existence or using exclusive access flags (such as O_EXCL), allowing an attacker to pre-populate a symlink at that path. When gzexe attempts to create and write to the file, it dereferences the symlink and overwrites the attacker-specified target. This violates the assumption that the temporary file path is both unique and under the application's control. The vulnerability is mapped to CWE-377 (Insecure Temporary File) and has been remediated in commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269.

Business impact

The practical impact depends on the attacker's capability and intent. Since gzexe is typically invoked by individual users compressing or decompressing files, the window of exploitation is limited to moments when the utility is actively running. An attacker must have local system access and the ability to predict or influence the target file path. However, successful exploitation could result in unauthorized modification or corruption of files belonging to the user running gzexe—potentially affecting configuration files, scripts, or data that the user has write access to. In environments where gzexe is used in automated or privileged contexts (though uncommon), the risk escalates. For most organizations, this is a lower-priority issue unless gzexe is central to critical workflows or deployed in multi-tenant environments where privilege isolation is relied upon.

Affected systems

This vulnerability affects GNU gzip installations where the gzexe utility is present and mktemp is not available in the user's PATH. gzexe is a bundled utility that compresses executable files in-place. Affected versions are those prior to the fix commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269. Organizations should check which gzip version is deployed and whether gzexe is actively used in their environment. The issue is most likely to surface on minimal or embedded systems, container images, or specialized environments where mktemp may not be present by default. Standard Linux distributions typically include mktemp, reducing exposure for mainstream users.

Exploitability

Exploitation requires local system access (AV:L) and relies on a race condition or predictability window that may be difficult to consistently hit (AC:H). The attacker must be able to create files in the same directory where gzexe will attempt to create its temporary file, typically /tmp or a location derived from the user's home directory. The attacker must also correctly predict the PID that gzexe will use, which is possible but requires either guessing, brute-forcing, or timing manipulation. No privileged access is required (PR:L), and no user interaction is needed (UI:N), but the overall attack chain is moderately complex. Practical exploitation is feasible in controlled scenarios (e.g., a co-resident attacker on a shared system), but the utility nature and limited execution context make widespread weaponization unlikely. The vulnerability is not tracked in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Apply the security patch from the GNU gzip project that incorporates commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269 or later. Verify the exact patched version number against the vendor's advisory or release notes before deploying. As an interim mitigation, ensure mktemp is available in the system PATH for all users who invoke gzexe, or restrict gzexe usage to trusted, controlled environments. Review your use cases for gzexe and assess whether this utility is necessary for your operations; many modern workflows use alternative compression tools or libraries that may have stronger security postures.

Patch guidance

Check your GNU gzip version using 'gzip --version'. Cross-reference the output against the vendor's release notes or security advisory to confirm whether your version includes commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269 or a later fix. Patches are typically available through your distribution's package manager. For Linux distributions, update gzip via your standard package management tool (apt, yum, pacman, etc.). For other systems or source-based deployments, download the latest gzip source from the GNU project and verify the commit history. Test that mktemp is available in the PATH after patching, and validate that gzexe functions correctly in your environment before retiring older installations. Document the patch deployment date and version for compliance and audit purposes.

Detection guidance

Monitor file system activity in /tmp and similar temporary directories for unexpected symlinks or rapid file creation patterns that may indicate pre-placement of symlinks by a local attacker. Log the execution of gzexe via auditd or similar kernel-level auditing, capturing both the PID and the temporary filenames it attempts to create. Correlate these logs with symlink creation events originating from other user contexts. Check for the presence of mktemp in the system PATH and alert if it becomes unavailable on systems where gzexe is known to be in use. Review system logs for file overwrite events affecting sensitive files shortly after gzexe execution. Consider leveraging integrity monitoring tools to detect unexpected changes to files that may have been targets of a symlink-based overwrite attack. These detections are most useful in multi-user or multi-tenant environments.

Why prioritize this

This vulnerability merits attention but is not critical. The CVSS 3.1 score of 4.7 (MEDIUM) reflects the local-only attack vector, high attack complexity, and lack of confidentiality or availability impact—only integrity is affected. Prioritize remediation if: (1) your organization runs multi-user systems where gzexe is actively used; (2) gzexe is invoked in automated scripts or services with elevated privileges; (3) you operate in a compliance regime that mandates patching all known vulnerabilities promptly. For single-user or locked-down systems where gzexe is rarely or never used, deferral to a regular patching cycle is acceptable. Given the absence of known exploitation in the wild (not in CISA's KEV list), this is a sound engineering and hygiene fix rather than an emergency response priority.

Risk score, explained

The CVSS 3.1 score of 4.7 (MEDIUM) is driven by a local-only attack surface (AV:L), high attack complexity (AC:H)—reflecting the race condition and PID prediction difficulty—and low privilege requirements (PR:L). Impact is limited to integrity (I:H), with no confidentiality or availability loss. The score appropriately reflects that while the vulnerability is real and could allow local file overwrite, the practical risk is constrained by environment, predictability, and use-case factors. It does not yet appear in CISA's Known Exploited Vulnerabilities catalog, indicating no widespread active exploitation has been observed. Organizations should treat this as a medium-priority but non-emergency patch.

Frequently asked questions