CVE-2026-33055: 
Rust vulnerability analysis and mitigation

CVE-2026-33055 is a tar archive differential parsing vulnerability in the tar-rs Rust crate (versions 0.4.44 and below) that allows an attacker to craft a malicious tar archive that is parsed differently by tar-rs compared to other standard tar implementations. The root cause is conditional logic in tar-rs that skips PAX size header overrides when the base header size is nonzero — the inverse of the behavior fixed in CVE-2025-62518 for the astral-tokio-tar project. This discrepancy can be exploited to smuggle hidden entries (e.g., symlinks) into archives that pass validation by one parser but are exposed by another. The vulnerability was published on March 20, 2026, and fixed in version 0.4.45. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 5.1 (Medium) (GitHub Advisory, Feedly).

The vulnerability is classified as CWE-843 (Access of Resource Using Incompatible Type / 'Type Confusion') and stems from a conditional check in src/archive.rs of tar-rs: the PAX size override was only applied when the base header size was zero, whereas compliant parsers (Go's archive/tar, astral-tokio-tar post-fix) unconditionally use the PAX size override. An attacker crafts a tar archive with a PAX extended header declaring a large file size (e.g., 2048 bytes) for a regular file whose base header reports a small size (e.g., 8 bytes). A malicious entry — such as a symlink pointing to /etc/shadow — is embedded in the inflated region between the two size boundaries. When tar-rs parses the archive, it reads only the small base header size and advances too little, exposing the hidden symlink; a compliant parser honors the PAX size and skips over it. A complete, runnable Python and Rust proof-of-concept demonstrating this differential is included in the GitHub security advisory (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to smuggle hidden archive entries — such as symlinks to sensitive files (e.g., /etc/shadow) — past validation layers that use a different tar parser, while those entries remain visible to tar-rs during extraction. This creates a security boundary bypass where server-side validation (e.g., crates.io using astral-tokio-tar) may approve a malicious archive that client-side tooling (e.g., cargo using tar-rs) then extracts with the hidden payload intact. The primary impact is on confidentiality and integrity, with no direct availability impact; affected systems include any application using tar-rs to parse archives in a pipeline that also involves other tar parsers (GitHub Advisory).

1. Craft the malicious archive: Use the published Python PoC to generate smuggle.tar. The script creates a PAX extended header (x type) declaring size=2048 for the next entry, followed by a regular file header with a base size of 8 bytes and only 8 bytes of actual content.
2. Embed the smuggled entry: Immediately after the regular file content, embed a symlink entry (e.g., pointing to /etc/shadow) within the inflated 2048-byte region that compliant parsers would skip over.
3. Submit the archive to a validation pipeline: Upload smuggle.tar to a system that uses astral-tokio-tar or another compliant parser for server-side validation. The compliant parser honors the PAX size (2048), skips the inflated region, and does not see the symlink — the archive passes validation.
4. Trigger extraction with tar-rs: When the validated archive is subsequently extracted by a client or server component using tar-rs (≤ 0.4.44), tar-rs reads only the base header size (8 bytes), advances too little, and exposes the hidden symlink entry.
5. Achieve objective: The extracted symlink (e.g., smuggled -> /etc/shadow) is now present on the filesystem, potentially enabling path traversal, privilege escalation, or data exfiltration depending on the application context (GitHub Advisory, Patch Commit).

• File System: Unexpected symlinks in extraction directories pointing to sensitive system files (e.g., /etc/shadow, /etc/passwd); presence of a file named smuggle.tar or archives with anomalous PAX extended headers (./PaxHeaders/ entries with size values inconsistent with the corresponding base headers.
• Logs: Application logs showing extraction of entries not present in server-side validation output; discrepancies between the number of entries reported by different tar tools on the same archive.
• Network: Submission of tar archives to upload endpoints where the PAX extended header size field significantly exceeds the base header size field (detectable via deep packet inspection or archive scanning at ingress).
• Process: Unexpected file access to sensitive paths (e.g., /etc/shadow) by processes performing tar extraction; symlink-following behavior by extraction processes leading to reads of files outside the intended extraction directory (GitHub Advisory).

The fix is available in tar-rs version 0.4.45, which unconditionally honors PAX size overrides, aligning behavior with astral-tokio-tar and Go's archive/tar. The patch modifies src/archive.rs to remove the conditional check, ensuring the PAX size always overrides the base header size when present (Patch Commit). Downstream consumers should update their Cargo.toml dependency to tar = "0.4.45" or later. Microsoft has released updates for affected Azure Linux (AZL3) and CBL-Mariner 2 Rust packages; IBM has issued a bulletin for IBM Bob (Microsoft MSRC, IBM Advisory). Amazon Linux 2 and Amazon Linux 2023 users should apply the relevant ALAS advisories. No configuration-based workaround is available; upgrading is the only remediation.

The vulnerability was discovered and reported by security researchers xokdvium, woodruffw (remediation reviewer), and 0xNakah, with the advisory published by alexcrichton on March 19, 2026 (GitHub Advisory). The issue was noted in the context of broader "tarmageddon" research (edera.dev) on differential tar parsing vulnerabilities, highlighting systemic risks in archive validation pipelines. The Rust security advisory database published RUSTSEC-2026-0068, and the Rust project released version 1.94.1 referencing this fix (Rust Blog). The advisory was rated "Low" severity by the maintainer despite the High CVSS v3.1 score, reflecting the limited real-world exploitability given crates.io's existing rejection of symlinks and hard links.