CVE-2026-33056: 
Rust vulnerability analysis and mitigation

CVE-2026-33056 is a symlink-following vulnerability in the tar-rs Rust crate (the tar library for reading/writing tar archives) that allows an attacker to modify permissions of arbitrary directories outside the extraction root. Affecting versions 0.4.44 and below, the flaw was disclosed on March 19–20, 2026, and patched in version 0.4.45. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 5.1 (Medium) (GitHub Advisory, Feedly).

The root cause is improper symbolic link resolution before file access (CWE-61 / CWE-59). In the unpack_dir function, when a directory entry already exists on disk, the code called fs::metadata() to verify it is a directory — but fs::metadata() follows symbolic links. An attacker can craft a tarball with two entries sharing the same name: first, a symlink foo pointing to an arbitrary external directory, then a directory entry foo. When unpacking, create_dir("foo") fails with EEXIST because the symlink is present; fs::metadata() then follows the symlink, sees a directory at the target, and allows processing to continue — subsequently applying chmod (mode bits from the directory entry) to the symlink target, which also follows the link. The fix replaces fs::metadata() with fs::symlink_metadata(), which detects and rejects symlinks rather than following them (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated attacker (with user interaction — the victim must unpack a crafted tarball) to modify the Unix permissions of arbitrary directories outside the intended extraction root. This is a pure integrity impact: confidentiality and availability are not directly affected, but permission tampering on sensitive system directories (e.g., /etc, /home, or application data directories) could enable privilege escalation, denial of service, or facilitate further attacks by making restricted directories world-writable. Downstream products embedding tar-rs versions ≤ 0.4.44 — including IBM Bob, Microsoft Azure Linux packages, and various Fedora/Ubuntu Rust packages — are also affected (GitHub Advisory, Feedly).

1. Craft the malicious tarball: Create a tar archive containing two entries with the same name. First, add a symlink entry named foo pointing to an arbitrary target directory outside the intended extraction root (e.g., /etc or /home/victim). Second, add a directory entry named foo with attacker-controlled mode bits (e.g., 0o777).
2. Deliver the tarball: Distribute the crafted tarball to a target system where an application using tar-rs ≤ 0.4.44 will unpack it — for example, via a file upload, package distribution, or social engineering.
3. Trigger extraction: Cause the victim application (or user) to call archive.unpack(destination) or equivalent on the malicious tarball.
4. Exploit symlink following: During unpacking, create_dir("foo") fails with EEXIST because the symlink already exists. The vulnerable fs::metadata() call follows the symlink, sees a directory at the target, and proceeds.
5. Permission modification achieved: The directory entry's mode bits are applied via chmod to the symlink target — modifying permissions on the external directory outside the extraction root, potentially making it world-writable or world-readable (GitHub Advisory, Patch Commit).

• File System: Unexpected permission changes (mode bits) on directories outside the tar extraction root, particularly sensitive directories such as /etc, /home, /var, or application data directories; presence of a symlink within the extraction directory pointing to an external path.
• Logs: Application or system logs showing tar extraction operations followed by unexpected chmod/permission change events on directories not within the extraction path; EEXIST errors during directory creation in tar extraction logs.
• Process: Rust applications or tools invoking tar-rs unpack/unpack_in functions on externally sourced archives; unexpected permission changes detected by file integrity monitoring tools (e.g., AIDE, Tripwire) on system directories.

Upgrade the tar Rust crate to version 0.4.45 or later, which replaces the vulnerable fs::metadata() call with fs::symlink_metadata() in unpack_dir, preventing symlinks from being treated as valid existing directories (GitHub Advisory, Patch Commit). As a workaround where upgrading is not immediately possible, avoid unpacking tar archives from untrusted sources, validate tarball contents before extraction, and consider using OS-level sandboxing (e.g., containers, namespaces) or the cap-std crate for capability-based filesystem access control. Downstream consumers — including IBM Bob, Microsoft Azure Linux Rust packages, and Fedora/Ubuntu packages — should apply their respective vendor updates (IBM Advisory, Microsoft MSRC).

The Rust security team published a blog post and the vulnerability was tracked as RUSTSEC-2026-0067 in the RustSec advisory database (RustSec). The issue generated discussion on Hacker News and was covered in the Rust community newsletter (This Week in Rust / Weekly Rust). The fix was also incorporated into the Rust 1.94.1 release (Rust Blog). Multiple Linux distributions (Fedora, Ubuntu, Amazon Linux) issued security advisories and package updates in response, reflecting broad downstream impact across the Rust ecosystem.