This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
elf2tab(4 total, 2 outdated, 2 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| chrono ⚠️ | ^0.4.2 | 0.4.44 | maybe insecure |
| elf | ^0.0.10 | 0.8.0 | out of date |
| structopt | ^0.2.10 | 0.3.26 | out of date |
| tar ⚠️ | ^0.4.15 | 0.4.45 | maybe insecure |
chrono: Potential segfault in `localtime_r` invocationsUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
tar: `unpack_in` can chmod arbitrary directories by following symlinksIn 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.
tar: tar-rs incorrectly ignores PAX size headers if header size is nonzeroVersions 0.4.44 and below of tar-rs have conditional logic that skips the PAX size header in cases where the base header size is nonzero.
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. This is almost the inverse of the astral-tokio-tar issue.
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. This can affect anything that uses the tar crate to
parse archives and expects to have a consistent view with other parsers.
This issue has been fixed in version 0.4.45.