Deps.rs

remexre / swipl-rs

[![dependency status](https://deps.rs/repo/github/remexre/swipl-rs/status.svg)](https://deps.rs/repo/github/remexre/swipl-rs)

This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate swipl

Dependencies

(3 total, all up-to-date)

CrateRequiredLatestStatus
 failure^0.1.10.1.8up to date
 failure_derive^0.1.10.1.8up to date
 lazy_static^1.0.01.5.0up to date

Crate swipl-sys

Dependencies

(2 total, 1 outdated, 1 insecure)

CrateRequiredLatestStatus
 gmp-mpfr-sys^1.1.01.7.0up to date
 ncurses ⚠️^5.91.06.0.1insecure

Build dependencies

(6 total, 3 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 bindgen^0.33.10.72.1out of date
 flate2^1.0.11.1.9up to date
 hashwriter^0.1.00.1.0up to date
 reqwest^0.8.50.13.2out of date
 sha2^0.7.00.11.0out of date
 tar ⚠️^0.4.140.4.45maybe insecure

Security Vulnerabilities

ncurses: Buffer overflow and format vulnerabilities in functions exposed without unsafe

RUSTSEC-2019-0006

ncurses exposes functions from the ncurses library which:

  • Pass buffers without length to C functions that may write an arbitrary amount of data, leading to a buffer overflow. (instr, mvwinstr, etc)
  • Passes rust &str to strings expecting C format arguments, allowing hostile input to execute a format string attack, which trivially allows writing arbitrary data to stack memory (functions in the printw family).

tar: `unpack_in` can chmod arbitrary directories by following symlinks

RUSTSEC-2026-0067

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.

tar: tar-rs incorrectly ignores PAX size headers if header size is nonzero

RUSTSEC-2026-0068

Versions 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.