GNU tar desync lets archives inject hidden files on extract
TL;DR — A GNU tar parsing mismatch means tar -t can miss files that tar -x will still write, so archive “preflight” inspection can be bypassed to inject hidden files onto disk.
What happened
GNU tar is the de-facto tar implementation on many Linux distributions and is widely used in developer workflows (source extraction, build tooling, CI/CD, and artifact handling).
An oss-security mailing list post (quoting an upstream bug-tar disclosure) describes a security issue in GNU tar 1.35 where listing and extraction produce different results for certain crafted archives. Specifically, when an archive contains non-data-bearing typeflags (symlink, character device, block device, FIFO) that also have a non-zero size field, the two modes disagree:
tar -trespects thesizefield and skips the data blocks.tar -xignores thesizefield and parses the data blocks as additional headers.
This desynchronization enables hidden file injection: files can be embedded such that they are not shown in tar -t output but are created on disk during tar -x extraction.
| Item | Source value |
|---|---|
| Affected software | GNU tar 1.35 |
| Issue | tar -t and tar -x disagree on archive contents |
| Impact | Hidden file injection during extraction (files written that were not listed) |
| CVE | CVE-2026-5704 (noted in the oss-security post as assigned by Red Hat) |
| Affected typeflags | '2' (symlink), '3' (chardev), '4' (blockdev), '6' (FIFO); '5' (directory) not affected |
The report’s example shows tar -tf listing two entries, while extraction writes a third file (injected.txt) that was not present in the listing.
Why it matters: tar extraction is a common boundary in build and deployment pipelines, and many “safe handling” workflows incorrectly assume tar -t (or any pre-extraction inspection based on listing) gives a complete view of what extraction will write.
Who is impacted
- Any workflow that extracts untrusted or semi-trusted tar archives using GNU tar, especially where operators or automation use
tar -tas a security gate before runningtar -x. - CI/CD systems and build tooling that ingest third-party source archives, release artifacts, or vendor tarballs, and perform “preflight” checks by listing contents.
- Environments where the extraction directory contains build triggers (e.g.,
Makefile, CI scripts, config files, or other files that influence subsequent steps), since injected files can change downstream behavior once written.
What to do now
- Follow upstream remediation guidance: the oss-security post links to an upstream patch discussion in the GNU tar bug tracker mailing list (bug-tar).
- Do not treat
tar -toutput as authoritative for safety decisions. If you must handle untrusted archives, treat listing as informational only and enforce safety with isolation/containment. - Apply GNU tar’s own operational guidance for untrusted archives (as quoted in the linked patch discussion):
"When extracting from an untrusted archive, it is therefore good practice to create an empty directory and run tar in that directory."
- If you operate a pipeline that ingests external archives, add detection/guardrails around extraction (e.g., extract into a dedicated empty directory, then validate the extracted filesystem state before consuming it).
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.