https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:48:16 +0000 https://cve.radiocsirt.org/vuln/cve-2026-33056 <p><strong>Affected:</strong> alexcrichton tar-rs</p> <p>tar-rs is a tar archive reading/writing library for Rust. In versions 0.4.44 and below, when unpacking a tar archive, the tar crate&#39;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.</p> <p><strong>Affected:</strong> alexcrichton tar-rs</p> <p>tar-rs is a tar archive reading/writing library for Rust. In versions 0.4.44 and below, when unpacking a tar archive, the tar crate&#39;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.</p> https://cve.radiocsirt.org/vuln/cve-2026-33056 https://cve.radiocsirt.org/vuln/ghsa-j4xf-2g29-59ph <p><strong>Affected:</strong> crates.io: tar</p> <p>## Summary</p> <p>When unpacking a tar archive, the `tar` crate&#39;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.</p> <p>## Reproducer</p> <p>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, `create_dir(&#34;foo&#34;)` 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&#39;s mode bits are then applied via `chmod`, which also follows the symlink — modifying the permissions of the external target directory.</p> <p>## Fix</p> <p>The fix is very simple, we now use `fs::symlink_metadata()` in `unpack_dir`, so symlinks are detected and rejected rather than followed.</p> <p>## Credit</p> <p>This issue was reported by @xokdvium - thank you!</p> <p><strong>Affected:</strong> crates.io: tar</p> <p>## Summary</p> <p>When unpacking a tar archive, the `tar` crate&#39;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.</p> <p>## Reproducer</p> <p>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, `create_dir(&#34;foo&#34;)` 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&#39;s mode bits are then applied via `chmod`, which also follows the symlink — modifying the permissions of the external target directory.</p> <p>## Fix</p> <p>The fix is very simple, we now use `fs::symlink_metadata()` in `unpack_dir`, so symlinks are detected and rejected rather than followed.</p> <p>## Credit</p> <p>This issue was reported by @xokdvium - thank you!</p> https://cve.radiocsirt.org/vuln/ghsa-j4xf-2g29-59ph