CVE-2026-5704 is a GNU tar 1.35 vulnerability caused by inconsistent handling of certain non-data-bearing tar entry typeflags during archive listing versus extraction. For archives containing symlink (typeflag 2), character device (3), block device (4), or FIFO (6) entries with a non-zero size field, tar -t respects the size field and skips the corresponding data blocks, while tar -x ignores that size field and interprets those same blocks as subsequent archive headers. This parser desynchronization allows an attacker to embed additional file headers and fully attacker-controlled file content inside the data region of such entries. As a result, files can be written to disk during extraction even though they are not shown during pre-extraction listing. The issue has been described as a listing/extraction desynchronization allowing hidden file injection, and a patch was published by Paul Eggert in the GNU tar project repository (commit b8d8a61b25588caca4efaf9bdd2e3f1a49da77e3).
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
tar -t output to validate archive contents before extraction. A crafted archive can appear benign or incomplete during inspection while causing additional hidden files to be created on disk during tar -x. Because the injected files are fully attacker-controlled, this can enable delivery of malicious payloads, unauthorized file placement, and downstream compromise depending on where extraction occurs and how extracted files are subsequently used. The vulnerability therefore creates a discrepancy between apparent and actual archive contents, undermining archive inspection, malware screening, and content validation processes.If you can’t patch tonight, do this now.
tar -t alone as a security control for archive inspection. Treat untrusted tar archives as potentially containing hidden extracted content even if listing output appears benign. Prefer extracting untrusted archives only in isolated environments, with strict filesystem permissions and post-extraction validation of actual created files. Where feasible, use alternative tar implementations reported to behave consistently for the demonstrated case, but only after independent verification in the target environment.Patch, then assume compromise.
b8d8a61b25588caca4efaf9bdd2e3f1a49da77e3. If vendor packages are used, apply the corresponding distribution update once available. Validate that the deployed tar implementation no longer exhibits divergent behavior between listing and extraction for non-data-bearing entries with non-zero size fields.No public exploits tracked yet. Mallory keeps watching.
No public exploit code observed for this vulnerability.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.