Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When a tar stream contains multiple "header" entries prior to a file entry, tar-rs applies the PAX header (x) to the next entry in the stream, regardless of type. For example, a stream of x - L - file (PAX, GNU longname, file) would result in x's extensions being applied to L rather than to file. Per POSIX pax, this is incorrect: a PAX header always applies to a file entry, not any intermediary entries. See the "pax Header Block" section for the specific prescription there. As a result of this, an attacker can contrive a tar containing a sequence of tar headers such that tar-rs applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling tar-rs specific skippage/extraction of members. In other words, a file can be contrived to extract differently on tar-rs than on other tar parsers. PoC This tar (zipped for size) demonstrates the desynchronization: with tar tvf: with tar-rs: In the above case, the PoC is not…
Recommended action: Upgrade to 0.4.46 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When unpacking a tar archive, the tar crate's unpackdir 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. Reproducer A malicious tarball contains two entries: (1) a symlink foo pointing to an arbitrary external directory, and (2) a directory entry foo/. (or just foo). When unpacked, createdir("foo") fails with EEXIST because the symlink is already on disk. The fs::metadata() check then follows the symlink, sees a directory at the target, and allows processing to continue. The directory entry's mode bits are then applied via chmod, which also follows the symlink — modifying the…
Recommended action: Upgrade to 0.4.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As part of CVE-2025-62518 the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. However, it was missed at the time that this project (the original Rust tar crate) had a conditional logic that skipped the PAX size header in the case that the base header size was nonzero - almost the inverse of the astral-tokio-tar issue. The problem here is that any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. Details https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600 https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344 PoC…
Recommended action: Upgrade to 0.4.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When unpacking a tarball that contains a symlink the tar crate may create directories outside of the directory it's supposed to unpack into. The function errors when it's trying to create a file, but the folders are already created at this point.
Recommended action: Upgrade to 0.4.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When unpacking a tarball with the unpackin-family of functions it's intended that only files within the specified directory are able to be written. Tarballs with hard links or symlinks, however, can be used to overwrite any file on the filesystem. Tarballs can contain multiple entries for the same file. A tarball which first contains an entry for a hard link or symlink pointing to any file on the filesystem will have the link created, and then afterwards if the same file is listed in the tarball the hard link will be rewritten and any file can be rewritten on the filesystem.
Recommended action: Upgrade to 0.4.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.