CVE-2026-5704

What it actually does

This vulnerability is an improper input validation flaw in GNU tar archive handling. A malicious archive can be crafted so that pre-extraction inspection, such as listing archive contents before unpacking, does not accurately reveal all files that will be written during extraction. When the archive is extracted, attacker-controlled hidden files can be injected onto the filesystem. The primary technical impact is integrity compromise: an attacker can cause unexpected files, scripts, configuration files, or application content to be created or overwritten depending on extraction location and privileges. Exploitation requires the archive to be obtained and extracted by a user, automation job, build pipeline, package process, or other workflow that invokes affected tar behavior.

Why it matters to the business

Organizations that process untrusted archives could unknowingly introduce malicious files into systems, containers, source trees, deployment packages, or build outputs. This may lead to tampered software artifacts, persistence through injected scripts or configuration, compromised application behavior, or supply-chain contamination. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the operational risk is higher in environments where tar archives are automatically extracted from external or semi-trusted sources, including CI/CD systems, container image builds, support file uploads, package mirrors, and hardened image workflows.

How an attack unfolds

An attacker prepares a tar archive with specially crafted metadata or path entries that cause a mismatch between what inspection tools report and what GNU tar actually writes during extraction. The attacker then delivers the archive through a channel where the target is likely to inspect and extract it, such as a downloaded package, source archive, container build context, support bundle, backup, or uploaded artifact. A user or automated process reviews the archive listing and sees no suspicious file, because the malicious payload is hidden from the pre-extraction view. When the archive is extracted with a vulnerable tar implementation, the hidden attacker-controlled file is written to disk. If extraction occurs in a sensitive location, the injected file may alter application behavior, add executable content, modify configuration, poison a build artifact, or stage later execution by another process.

How to fix it

Upgrade GNU tar and any vendor-supplied tar packages as soon as fixed packages are available from the operating system or distribution vendor. Because no fixed versions were provided in the input, track vendor advisories for GNU tar, Red Hat Enterprise Linux, and Red Hat hardened images and apply the first available security update. Rebuild container images, hardened base images, and appliance images that include the vulnerable tar package after updating. Until patches are available, avoid extracting untrusted tar archives with affected tar versions; process untrusted archives only in isolated, disposable sandboxes with no sensitive mounted paths; extract as an unprivileged user; prevent extraction into source trees, deployment directories, system paths, and privileged locations; and compare archive listings using multiple independent tools or by extracting into a temporary empty directory and inspecting the resulting filesystem before use. Where possible, block or quarantine externally supplied tar archives in automated workflows unless they come from trusted, authenticated sources and are verified by signature or checksum.

How to confirm the fix worked

Confirm exposure by inventorying systems, build images, containers, and developer environments for installed GNU tar versions using package manager data and `tar --version`. Validate remediation by confirming the installed package version matches the vendor-fixed version once published, and by ensuring rebuilt container and hardened images no longer include the vulnerable package. Test archive-processing workflows to verify that untrusted archives are extracted only in isolated temporary directories with least privilege. For high-assurance validation, use a known benign proof-of-concept test archive from a trusted vendor or security advisory, if available, and confirm that inspection and extraction behavior are consistent after patching. Also verify that CI/CD, package ingestion, upload, and support-bundle workflows do not extract externally supplied tar files directly into sensitive directories.

Typical attack path

1. Identify a target workflow that accepts or downloads tar archives from external or less-trusted sources.
2. Craft a malicious tar archive that abuses the validation flaw so inspection output differs from extraction behavior.
3. Place attacker-controlled content inside the hidden or misleading archive entry.
4. Deliver the archive through email, download links, source distribution, package ingestion, artifact upload, support bundle exchange, container build input, or another archive-processing path.
5. Rely on a user, script, CI job, packaging process, or container build step to inspect and then extract the archive with an affected GNU tar version.
6. Cause the hidden file to be written to the filesystem during extraction.
7. Leverage the injected file if it is later executed, loaded as configuration, packaged into a release artifact, or included in a deployment image.

How to detect it

To determine whether exploitation may already have occurred, focus on systems and workflows that extracted tar archives from untrusted or semi-trusted sources after the vulnerability was introduced or disclosed. Review shell history, process execution telemetry, EDR events, CI/CD job logs, package ingestion logs, artifact upload logs, container build logs, and server-side file-processing logs for tar extraction commands operating on externally supplied archives. Correlate tar extraction events with subsequent unexpected file creation, modification, or overwrite activity in the extraction directory and nearby application, build, or deployment paths. Look for archive-processing jobs where `tar -tf` or equivalent inspection occurred before extraction but the post-extraction directory contains additional files not present in the inspection output. Examine suspicious archives offline in a sandbox using multiple tools and compare reported archive entries against actual files written after extraction. Prioritize investigation when extraction was performed as a privileged user, inside a source tree, during image builds, in release packaging, or in directories later consumed by interpreters, service managers, build tools, or deployment systems. There are no universal network indicators or payload filenames for this vulnerability because attacker-controlled file names and contents vary by campaign.

What your security team should do

• Prioritize patch tracking for GNU tar packages in Red Hat Enterprise Linux, Red Hat hardened images, and any systems or containers that process external archives.
• Inventory all automated workflows that run tar extraction, especially CI/CD pipelines, container builds, package ingestion jobs, backup restores, artifact unpacking, and support-bundle processing.
• Temporarily treat externally supplied tar archives as unsafe unless they are authenticated, signed, and extracted inside a disposable sandbox.
• Prevent archive extraction into privileged paths, application runtime directories, source repositories, deployment directories, and image build roots unless the archive source is trusted.
• Run extraction as an unprivileged account and use an empty temporary directory followed by post-extraction inspection before moving files into production paths.
• Rebuild base images and downstream containers after vendor-fixed tar packages are available.
• Add monitoring for unexpected file creation following tar extraction events in build, packaging, and server-side upload workflows.
• Educate engineering and operations teams that archive listing alone may not be sufficient to validate archive safety on affected systems.