CVE-2026-41991

What it actually does

The flaw is a local race-condition/symlink vulnerability in GNU gzip's gzexe helper. If mktemp is unavailable in the executing user's PATH, gzexe falls back to a predictable temporary filename derived only from its process ID and creates or writes to it without an atomic exclusive-create check. A local attacker who can anticipate or brute-force the temporary path can pre-create it as a symbolic link to another file writable by the gzexe user. When the victim runs gzexe, the utility follows the symlink and overwrites the linked target with the victim user's privileges. The practical impact is file overwrite or corruption within the victim's write permissions; impact is higher if gzexe is run by an administrator or inside privileged automation.

Why it matters to the business

Exploitation can corrupt scripts, configuration files, or other writable files on affected Unix-like systems, potentially disrupting operations or enabling follow-on privilege abuse if a privileged user or job runs gzexe. The exposure is local and requires a specific condition where mktemp is missing from PATH plus a victim execution of gzexe, so broad internet-scale exploitation is unlikely. EPSS is very low and stable at 0.00117 with no known exploited-in-the-wild or ransomware association, but organizations that package, build, or compress executables in shared multi-user environments should still remediate because the affected component is common and the fix is straightforward.

How an attack unfolds

An attacker first obtains local code execution or shell access on the same system where another user, build process, or administrator may run gzexe. The attacker ensures or waits for a situation where gzexe cannot locate mktemp in the victim's PATH, causing it to use the insecure PID-based temporary filename fallback. The attacker predicts likely process IDs, creates symbolic links at the expected temporary-file paths, and points them to files the victim user can overwrite. When the victim runs gzexe, gzexe writes through the symlink instead of creating a fresh temporary file, overwriting the attacker-selected target. The attacker then leverages the modified or corrupted file for disruption, persistence, or privilege escalation if the overwritten file is later executed or trusted by a higher-privileged process.

How to fix it

Upgrade GNU gzip to a version that includes commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269 or apply the vendor backport for this issue. Where package-specific fixed versions are not available, use the operating system or distribution security advisory as the authoritative source and update the gzip package through the normal package manager. As interim mitigation, ensure mktemp is installed and available in all execution contexts that may run gzexe, especially cron jobs, build workers, sudo-preserved environments, and restricted PATH configurations; however, this should be treated as a mitigation, not a replacement for patching. Avoid running gzexe as root or from privileged automation on shared systems until patched. Restrict untrusted local users from writing to shared temporary directories where possible by enforcing sticky-bit permissions and monitoring symlink creation, but do not rely on permissions alone to eliminate the race condition.

How to confirm the fix worked

Confirm the installed gzip/gzexe package includes the vendor fix or the upstream commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269. On systems managed by a distribution, verify the package changelog or security advisory rather than relying only on upstream version strings, because fixes may be backported. Inspect the gzexe script and confirm it no longer falls back to a PID-only temporary filename without exclusive creation when mktemp is unavailable. Validate that mktemp is installed and resolves in the PATH used by shells, cron, systemd units, CI runners, sudo sessions, and build scripts that call gzexe. For exposure testing, run only in a controlled non-production environment and confirm gzexe creates temporary files atomically and refuses to follow pre-existing symlinks.

Typical attack path

1. Gain local access to a Unix-like system with a vulnerable GNU gzip/gzexe installation.
2. Identify that gzexe is present and that mktemp may be absent or unavailable in the victim execution PATH.
3. Monitor or estimate likely process IDs for the victim user's future gzexe execution.
4. Pre-create predictable temporary path names as symbolic links to attacker-selected files writable by the victim.
5. Wait for or induce the victim, script, or automation to run gzexe.
6. Allow gzexe to follow the symbolic link and overwrite the target file with the victim user's privileges.
7. Use the overwritten file to cause disruption, alter behavior, or support follow-on privilege escalation where possible.

How to detect it

Look for evidence of local exploitation by correlating process execution, filesystem, and authentication telemetry. Useful sources include auditd logs, Linux process accounting, EDR telemetry, shell history, sudo logs, cron/systemd journal entries, CI runner logs, and filesystem integrity monitoring. Investigate gzexe executions where mktemp was missing from PATH, PATH was unusually restricted, or the parent process was cron, sudo, a build runner, or privileged automation. Search for symbolic links created shortly before gzexe execution in world-writable temporary directories, especially names matching PID-like gzexe temporary-file patterns. Review target files overwritten at the same timestamp as gzexe execution, particularly scripts, shell startup files, service unit files, cron files, build artifacts, and application configuration files writable by the gzexe user. There are no known public threat actors or in-the-wild campaigns associated with this issue as of the provided data, so detection should focus on behavioral evidence rather than known malware indicators.

• gzexe
• /usr/bin/gzexe
• /bin/gzexe
• mktemp: not found
• mktemp: command not found
• /tmp/gzexe[0-9]+
• /var/tmp/gzexe[0-9]+
• ln -s
• ln -sf
• ln --symbolic
• PATH=.*gzexe
• comm="gzexe"
• exe="/usr/bin/gzexe"
• SYMLINK.*gzexe[0-9]+
• CREATE.*gzexe[0-9]+
• audit.*gzexe
• type=EXECVE.*gzexe
• type=SYSCALL.*symlink
• type=SYSCALL.*symlinkat

What your security team should do

• Inventory systems with GNU gzip/gzexe installed, prioritizing shared shell servers, build systems, packaging hosts, CI runners, and administrative jump hosts.
• Patch gzip using vendor packages or a build containing commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269.
• Verify mktemp is installed and available in non-interactive execution contexts as an interim control.
• Avoid privileged gzexe use until patched; replace workflows that run gzexe as root with least-privilege execution where feasible.
• Enable or tune local process and file monitoring for suspicious symlink creation in temporary directories followed by gzexe execution.
• Review recent file corruption or unexpected modification events around gzexe executions, especially where the process ran with elevated privileges.
• Because EPSS is low, not KEV-listed, and no public exploit maturity is reported, handle through normal patch SLAs unless the environment is multi-user or uses gzexe in privileged automation.