Mar 20, 2026·6 min read·3 visits
The tar-rs library fails to unconditionally honor PAX extended header size attributes, creating a parser differential against POSIX-compliant implementations. This discrepancy enables attackers to craft 'chameleon' archives that hide malicious entries from security scanners but are executed upon extraction by tar-rs.
A parser differential vulnerability in the Rust tar-rs crate <= 0.4.44 allows attackers to smuggle hidden TAR entries past compliant security validators. The vulnerability arises from non-compliant handling of PAX extended header size overrides.
CVE-2026-33055 is a parser differential vulnerability affecting the tar-rs crate, a standard Rust library utilized for reading and writing TAR archives. The vulnerability manifests in the library's non-compliant processing of Portable Archive Interchange (PAX) extended headers. These extended headers are heavily utilized to specify metadata that exceeds the traditional limits of the USTAR format.
The flaw occurs because tar-rs versions up to 0.4.44 selectively ignore PAX size overrides under specific conditions. POSIX.1-2001 standards strictly mandate that an extended header attribute must unconditionally override the corresponding field in the subsequent USTAR header. By violating this specification, tar-rs interprets archive boundaries differently than compliant parsers.
This behavior introduces a parser differential, a class of vulnerability where two separate parsing engines extract varying semantic meaning from the same input sequence. Attackers exploit this differential to bypass upstream archive validation systems. A security scanner utilizing a compliant parser will observe a benign archive structure, while the downstream tar-rs implementation will extract hidden, potentially malicious entries.
The vulnerability is localized within the EntriesFields::next() method in src/archive.rs. The logic responsible for determining the size of the current TAR entry fails to adhere to the PAX specification regarding metadata prioritization.
In standard TAR parsing, the base USTAR header provides a 12-byte octal field dictating the file size. When a PAX extended header of type x precedes the standard header, it often contains a size attribute designed to support files larger than 8GB or provide sub-byte precision.
The vulnerable implementation applies conditional logic to this evaluation. It reads the base USTAR size, and only falls back to the PAX size if the USTAR size evaluates to exactly zero. If the USTAR size is any non-zero integer, the PAX size is discarded entirely.
This incorrect conditional assumption is the root cause of CVE-2026-33055. Because standard utilities like GNU tar or Go's archive/tar implement unconditional overrides, a crafted archive containing conflicting sizes in the PAX and USTAR headers will force the two parsers to consume different byte ranges as file data, thereby desynchronizing their respective views of the archive structure.
The divergence in parsing logic is evident in the pre-patch implementation of the entry_size evaluation. The codebase incorrectly gated the application of the pax_size variable behind a zero-check on the base header size.
// Vulnerable Implementation (tar-rs <= 0.4.44)
let mut size = header.entry_size()?;
if size == 0 {
if let Some(pax_size) = pax_size {
size = pax_size;
}
}The patch applied in commit de1a5870e603758f430073688691165f21a33946 resolves this differential by realigning the logic with the POSIX.1-2001 standard. The condition if size == 0 was removed, ensuring the extended header takes absolute precedence.
// Patched Implementation (tar-rs >= 0.4.45)
let mut size = header.entry_size()?;
if let Some(pax_size) = pax_size {
size = pax_size;
}By unconditionally applying pax_size when it is present, tar-rs now computes the correct data block bounds. This fix eliminates the parser differential, ensuring that downstream extraction aligns precisely with upstream security validation.
Exploitation relies on generating a "chameleon" archive to execute an entry smuggling attack. The attacker constructs an archive sequence where the metadata intentionally conflicts. The first component is a PAX header declaring a large file size, immediately followed by a USTAR header declaring a small file size.
The data payload following these headers contains standard file bytes up to the USTAR size limit, padded with null bytes, and eventually containing a secondary, fully-formed TAR header (the "smuggled" entry). This smuggled entry often represents a malicious payload, such as a symbolic link pointing to a restricted path like /etc/shadow.
When a compliant security scanner processes this archive, it reads the PAX size (2048 bytes). It treats the next 2048 bytes, including the smuggled symlink header, as opaque file data. The scanner finds no malicious files and approves the archive.
Subsequently, tar-rs processes the same archive. It reads the USTAR size (8 bytes), ignores the PAX size, and consumes only the first 512-byte block containing the 8 bytes of data. It then treats the next 512-byte block as a new TAR header, immediately parsing and extracting the smuggled symlink.
The primary impact of CVE-2026-33055 is the evasion of security controls. Organizations frequently deploy architectures where an upstream service (like a WAF or antivirus scanner) validates user-uploaded archives before passing them to a backend processing service. If the backend relies on tar-rs, attackers can bypass the validation tier entirely.
Once the smuggled entry is processed by tar-rs, the consequences depend on the nature of the hidden payload. The most common exploitation paths involve writing arbitrary files to the filesystem or creating symbolic links that facilitate directory traversal and unauthorized read/write operations.
The vulnerability is scored as Medium (CVSS 5.1). The relatively moderate score reflects the requirement for a specific dual-parser architectural setup to achieve security bypass. If tar-rs is the only parser interacting with the archive, the malicious entry will execute, but no specific bypass occurs. This issue operates as the inverse of CVE-2025-62518 (Tarmageddon), where parsers failed to skip correctly rather than surfacing hidden data.
The definitive remediation for CVE-2026-33055 is upgrading the tar-rs dependency to version 0.4.45 or higher. Development teams should modify their Cargo.toml files to reflect this requirement and rebuild their applications to statically link the patched library.
For organizations unable to immediately deploy patched software, mitigation strategies involve enforcing strict limits on archive structures at the validation tier. Security scanners should be configured to reject archives containing conflicting file size declarations between PAX and USTAR headers, effectively blocking chameleon archives before they reach vulnerable endpoints.
Security engineers should execute cargo audit across all Rust repositories to identify transitive dependencies utilizing vulnerable versions of tar-rs. Continuous monitoring for archive parsing discrepancies is recommended for high-security environments handling untrusted user uploads.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
tar-rs Alex Crichton / Rust Crate Ecosystem | <= 0.4.44 | 0.4.45 |
| Attribute | Detail |
|---|---|
| Vulnerability Type | Parser Differential / Type Confusion |
| CWE ID | CWE-843 |
| CVSS v4.0 | 5.1 (Medium) |
| EPSS Score | 0.00040 (0.04%) |
| Affected Component | tar-rs src/archive.rs (EntriesFields::next) |
| Exploit Status | Proof of Concept available |
| Attack Vector | Crafted TAR archive upload |
The program accesses a resource using an incompatible type, leading to a type confusion or misinterpretation of structured data.