RUSTSEC-2026-0067: `unpack_in` can chmod arbitrary directories by following symlinks

What to do

1. See which version you have: cargo tree -i tar (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p tar. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example tar = "0.4.45") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

In versions 0.4.44 and below of tar-rs, when unpacking a tar archive, the tar crate's unpack_dir function uses fs::metadata() to check whether a path that already exists is a directory. Because fs::metadata() follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory , and subsequently apply chmod to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

This issue has been fixed in version 0.4.45.

References

• Package: crates.io/crates/tar
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0067.html

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for tar

• Vulnerability HighRUSTSEC-2018-0002 · 2018-06-29Links in archives can overwrite any existing file
• Vulnerability HighRUSTSEC-2021-0080 · 2021-07-19Links in archive can create arbitrary directories
• VulnerabilityRUSTSEC-2026-0068 · 2026-03-19tar-rs incorrectly ignores PAX size headers if header size is nonzero
• VulnerabilityGHSA-3pv8-6f4r-ffg2 · 2026-05-29tar has a PAX header desynchronization issue

Full security history of tar