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.
Unix-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.
On certain platforms, if a user has more than 16 groups, the
nix::unistd::getgrouplist function will call the libc getgrouplist
function with a length parameter greater than the size of the buffer it
provides, resulting in an out-of-bounds write and memory corruption.
The libc getgrouplist function takes an in/out parameter ngroups
specifying the size of the group buffer. When the buffer is too small to
hold all of the requested user's group memberships, some libc
implementations, including glibc and Solaris libc, will modify ngroups
to indicate the actual number of groups for the user, in addition to
returning an error. The version of nix::unistd::getgrouplist in nix
0.16.0 and up will resize the buffer to twice its size, but will not
read or modify the ngroups variable. Thus, if the user has more than
twice as many groups as the initial buffer size of 8, the next call to
getgrouplist will then write past the end of the buffer.
The issue would require editing /etc/groups to exploit, which is usually
only editable by the root user.
Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.
Patches
No patch is yet available, however work is underway to migrate to a fully constant-time implementation.
Workarounds
The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.
References
This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.
rustls: rustls network-reachable panic in `Acceptor::accept`
A bug introduced in rustls 0.23.13 leads to a panic if the received
TLS ClientHello is fragmented. Only servers that use
rustls::server::Acceptor::accept() are affected.
Servers that use tokio-rustls's LazyConfigAcceptor API are affected.
Servers that use tokio-rustls's TlsAcceptor API are not affected.
Servers that use rustls-ffi's rustls_acceptor_accept API are affected.
tracing-subscriber: Logging user input may result in poisoning logs with ANSI escape sequences
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.
In the unique reclaim path of BytesMut::reserve, the condition
if v_capacity >= new_cap + offset
uses an unchecked addition. When new_cap + offset overflows usize in release builds, this condition may incorrectly pass, causing self.cap to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as spare_capacity_mut() then trust this corrupted cap value and may create out-of-bounds slices, leading to UB.
This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
PoC
use bytes::*;
fn main() {
let mut a = BytesMut::from(&b"hello world"[..]);
let mut b = a.split_off(5);
// Ensure b becomes the unique owner of the backing storage
drop(a);
// Trigger overflow in new_cap + offset inside reserve
b.reserve(usize::MAX - 6);
// This call relies on the corrupted cap and may cause UB & HBO
b.put_u8(b'h');
}
Workarounds
Users of BytesMut::reserve are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
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
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
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.