Stream: git-wasmtime

Topic: wasmtime / issue #12830 RUSTSEC-2026-0067: `unpack_in` ca...

Wasmtime GitHub notifications bot (Mar 24 2026 at 00:13):

github-actions[bot] opened issue #12830:

unpack_in can chmod arbitrary directories by following symlinks

Details
Package	tar
Version	0.4.41
Date	2026-03-19
Patched versions	>=0.4.45

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()][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.

[fs-metadata]: https://doc.rust-lang.org/std/fs/fn.metadata.html

See advisory page for additional details.

Wasmtime GitHub notifications bot (Mar 25 2026 at 00:22):

pchickey closed issue #12830:

unpack_in can chmod arbitrary directories by following symlinks

Details
Package	tar
Version	0.4.41
Date	2026-03-19
Patched versions	>=0.4.45

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()][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.

[fs-metadata]: https://doc.rust-lang.org/std/fs/fn.metadata.html

See advisory page for additional details.

Last updated: Apr 12 2026 at 23:10 UTC