The git2 and libgit2-sys crates are Rust wrappers around the libgit2 C library. It was discovered that libgit2 1.5.0 and below did not verify SSH host keys when establishing an SSH connection, exposing users of the library to Man-In-the-Middle attacks.

The libgit2 team assigned CVE-2023-22742 to this vulnerability. The following versions of the libgit2-sys Rust crate have been released:

• libgit2-sys 0.14.2, updating the underlying libgit2 C library to version 1.5.1.
• libgit2-sys 0.13.5, updating the underlying libgit2 C library to version 1.4.5.

A new git2 crate version has also been released, 0.16.1. This version only bumps its libgit2-sys dependency to ensure no vulnerable libgit2-sys versions are used, but contains no code changes: if you update the libgit2-sys version there is no need to also update the git2 crate version.

You can learn more about this vulnerability in libgit2's advisory

The libgit2 project fixed three security issues in the 1.7.2 release. These issues are:

• The git_revparse_single function can potentially enter an infinite loop on a well-crafted input, potentially causing a Denial of Service. This function is exposed in the git2 crate via the Repository::revparse_single method.
• The git_index_add function may cause heap corruption and possibly lead to arbitrary code execution. This function is exposed in the git2 crate via the Index::add method.
• The smart transport negotiation may experience an out-of-bounds read when a remote server did not advertise capabilities.

The libgit2-sys crate bundles libgit2, or optionally links to a system libgit2 library. In either case, versions of the libgit2 library less than 1.7.2 are vulnerable. The 0.16.2 release of libgit2-sys bundles the fixed version of 1.7.2, and requires a system libgit2 version of at least 1.7.2.

It is recommended that all users upgrade.

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.

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.

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.