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.

Crate cargo

Dependencies

(70 total, 22 outdated, 4 possibly insecure)

CrateRequiredLatestStatus
 annotate-snippets^0.11.20.12.13out of date
 anstream^0.6.131.0.0out of date
 anstyle^1.0.61.0.14up to date
 anyhow^1.0.821.0.102up to date
 base64^0.22.10.22.1up to date
 bytesize^1.32.3.1out of date
 cargo-credential^0.4.20.4.9up to date
 cargo-credential-libsecret^0.4.70.5.5out of date
 cargo-credential-macos-keychain^0.4.70.4.20up to date
 cargo-credential-wincred^0.4.70.4.20up to date
 cargo-platform^0.1.50.3.2out of date
 cargo-util^0.2.140.2.27up to date
 cargo-util-schemas^0.5.00.12.0out of date
 clap^4.5.44.6.0up to date
 color-print^0.3.60.3.7up to date
 crates-io^0.40.40.40.17up to date
 curl^0.4.460.4.49up to date
 curl-sys^0.4.720.4.87+curl-8.19.0up to date
 filetime^0.2.230.2.27up to date
 flate2^1.0.301.1.9up to date
 git2^0.19.00.20.4out of date
 git2-curl^0.20.00.21.0out of date
 gix^0.64.00.81.0out of date
 glob^0.3.10.3.3up to date
 hex^0.4.30.4.3up to date
 hmac^0.12.10.13.0out of date
 home^0.5.90.5.12up to date
 http-auth^0.1.90.1.10up to date
 humantime^2.1.02.3.0up to date
 ignore^0.4.220.4.25up to date
 im-rc^15.1.015.1.0up to date
 indexmap^2.2.62.13.0up to date
 itertools^0.13.00.14.0out of date
 jobserver^0.1.280.1.34up to date
 lazycell^1.3.01.3.0up to date
 libc^0.2.1540.2.184up to date
 libgit2-sys^0.17.00.18.3+1.9.2out of date
 memchr^2.7.22.8.0up to date
 opener^0.7.00.8.4out of date
 openssl ⚠️^0.10.570.10.76maybe insecure
 os_info^3.8.23.14.0up to date
 pasetors^0.6.80.7.8out of date
 pathdiff^0.2.10.2.3up to date
 rand^0.8.50.10.0out of date
 regex^1.10.41.12.3up to date
 rusqlite^0.31.00.39.0out of date
 rustfix^0.8.20.9.4out of date
 same-file^1.0.61.0.6up to date
 semver^1.0.221.0.27up to date
 serde^1.0.1991.0.228up to date
 serde-untagged^0.1.50.1.9up to date
 serde_ignored^0.1.100.1.14up to date
 serde_json^1.0.1161.0.149up to date
 sha1^0.10.60.11.0out of date
 shell-escape^0.1.50.1.5up to date
 supports-hyperlinks^3.0.03.2.0up to date
 supports-unicode^3.0.03.0.0up to date
 tar ⚠️^0.4.400.4.45maybe insecure
 tempfile^3.10.13.27.0up to date
 time ⚠️^0.3.360.3.47maybe insecure
 toml^0.8.141.1.2+spec-1.1.0out of date
 toml_edit^0.22.140.25.10+spec-1.1.0out of date
 tracing^0.1.400.1.44up to date
 tracing-chrome^0.7.20.7.2up to date
 tracing-subscriber ⚠️^0.3.180.3.23maybe insecure
 unicase^2.7.02.9.0up to date
 unicode-width^0.1.120.2.2out of date
 url^2.5.02.5.8up to date
 walkdir^2.5.02.5.0up to date
 windows-sys^0.520.61.2out of date

Dev dependencies

(5 total, 4 outdated)

CrateRequiredLatestStatus
 annotate-snippets^0.11.20.12.13out of date
 cargo-test-support^0.3.00.10.0out of date
 gix^0.64.00.81.0out of date
 same-file^1.0.61.0.6up to date
 snapbox^0.6.91.2.0out of date

Security Vulnerabilities

openssl: Use-After-Free in `Md::fetch` and `Cipher::fetch`

RUSTSEC-2025-0022

When a Some(...) value was passed to the properties argument of either of these functions, a use-after-free would result.

In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior).

The maintainers thank quitbug for reporting this vulnerability to us.

tracing-subscriber: Logging user input may result in poisoning logs with ANSI escape sequences

RUSTSEC-2025-0055

Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:

  • Manipulate terminal title bars
  • Clear screens or modify terminal display
  • Potentially mislead users through terminal manipulation

In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.

This was patched in PR #3368 to escape ANSI control characters from user input.

time: Denial of Service via Stack Exhaustion

RUSTSEC-2026-0009

Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario.

Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.

Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of the stack consumed would be at most a factor of the length of the input.

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.