See how rust compares to other vendors in security performance
ring::aead::quic::HeaderProtectionKey::newmask() may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 232 packets sent and/or received.
On 64-bit targets operations using ring::aead::{AES128GCM, AES256GCM} may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.
Overflow checking is not enabled in release mode by default, but RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.
The arrayref crate 0.3.10 for Rust can trigger execution of malicious code when compiling a project that uses the crate, because it has a rogue dependency that registers with a command-and-control server to offer arbitrary code execution.
A flaw was found in the user's crate for Rust. This vulnerability allows privilege escalation via incorrect group listing when a user or process has fewer than exactly 1024 groups, leading to the erroneous inclusion of the root group in the access list.
Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.
Cargo between 1.68 and 1.96 incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.
End of life: 8/20/2026, Latest version: 1.97.1
Issue 1: Failure to quote characters
Affected versions of this crate allowed the bytes { and \xa0 to appear unquoted and unescaped in command arguments.
If the output of quote or join is passed to a shell, then what should be a single command argument could be interpreted as multiple arguments.
This does not directly allow arbitrary command execution (you can't inject a command substitution or similar). But depending on the command you're running, being able to inject multiple arguments where only one is expected could lead to undesired consequences, potentially including arbitrary command execution.
The flaw was corrected in version 1.2.1 by escaping additional characters. Updating to 1.3.0 is recommended, but 1.2.1 offers a more minimal fix if desired.
Workaround: Check for the bytes { and \xa0 in quote/join input or output.
(Note: { is problematic because it is used for glob expansion. \xa0 is problematic because it's treated as a word separator in [specific environments][solved-xa0].)
Issue 2: Dangerous API w.r.t. nul bytes
Version 1.3.0 deprecates the quote and join APIs in favor of tryquote and tryjoin, which behave the same except that they have Result return type, returning Err if the input contains nul bytes.
Strings containing nul bytes generally cannot be used in Unix command arguments or environment variables, and most shells cannot handle nul bytes even internally. If you try to pass one anyway, then the results might be security-sensitive in uncommon scenarios. [More details here.][nul-bytes]
Due to the low severity, the behavior of the original quote and join APIs has not changed; they continue to allow nuls.
Workaround: Manually check for nul bytes in quote/join input or output.
Issue 3: Lack of documentation for interactive shell risks
The quote family of functions does not and cannot escape control characters. With non-interactive shells this is perfectly safe, as control characters have no special effect. But if you writing directly to the standard input of an interactive shell (or through a pty), then control characters [can cause misbehavior including arbitrary command injection.][control-characters]
This is essentially unfixable, and has not been patched. But as of version 1.3.0, documentation has been added.
Future versions of shlex may add API variants that avoid the issue at the cost of reduced portability.
[solved-xa0]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#solved-xa0 [nul-bytes]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#nul-bytes [control-characters]: https://docs.rs/shlex/latest/shlex/quotingwarning/index.html#control-characters-interactive-contexts-only
The following advisories have been posted to both https://blog.rust-lang.org/ and https://groups.google.com/g/rustlang-security-announcements/ earlier this week: CVE-2026-5222: Cargo can be coerced to share credentials between registries
The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the [sparse index protocol][1]. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.
This vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.
Overview
Originally Cargo only supported storing a registry's index within git repositories. Most git hosting solutions allow accessing a git repository with or without the .git suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for https://example.com/index to be used for https://example.com/index.git.
This normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with .git as different URLs than those without the suffix.
If the following conditions apply:
https://example.com/index is a sparse index. https://example.com/index allows crates to depend on crates from any other registry. The attacker is able to publish crates on https://example.com/index. The attacker is able to upload arbitrary files to https://example.com/index.git.
...the attacker could configure https://example.com/index.git to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.
When the attacker then publishes a crate foo to https://example.com/index depending on a crate bar from https://example.com/index.git, and tricks the victim into downloading foo, Cargo will think the two registries share the same credential and send the victim's Cargo token to the malicious registry.
Mitigations
Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the .git suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.
Affected versions
All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.
Acknowledgements
We'd like to thank Christos Papakonstantinou for reporting this to us according to the [Rust security policy][2].
We also want to thank the members of the Rust project who helped us address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.
[1]: https://doc.rust-lang.org/cargo/reference/registries.html#registry-protocols [2]: https://rust-lang.org/policies/security
CVE-2026-5223: Crates in third party registries can override the cached source of other crates
The Rust Security Response Team was notified that Cargo incorrectly handled symlinks inside of crate tarballs downloaded from third-party registries, allowing a malicious crate to override the source code of another crate from the same registry.
This vulnerability is tracked as CVE-2026-5223. The severity of the vulnerability is medium for users of third-party registries. Users of crates.io are not affected, as crates.io forbids uploading crates containing any symlink.
Overview
When building a crate, Cargo extracts its source code in a local cache (stored within ~/.cargo), reusing it for any future build. Cargo includes protections to prevent any file from being extracted outside of the crate's own cache directory.
It was discovered that it's possible to craft a malicious tarball able to extract files one level below the crate's own cache directory. With the way the cache is structured, that allowed the malicious crate to override the cache of other crates belonging to the same registry.
Mitigations
Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject extracting any symlink within crate tarballs, regardless of whether they come from crates.io (which already forbids them) or third-party registries. Note that Cargo never added symlinks when running cargo package or cargo publish, so the impact of this should be minimal.
Users who are not able to upgrade to the most recent Rust version are recommended to audit the contents of their registry for the presence of any symlink, and to configure their registry to reject symlink (if such option is available).
Affected versions
All versions of Cargo shipped before Rust 1.96.0 are affected.
Acknowledgements
We'd like to thank Christos Papakonstantinou for reporting this to us according to the [Rust security policy][1].
We also want to thank the members of the Rust project who helped us address the vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for advising during the disclosure.
[1]: https://rust-lang.org/policies/security -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
End of life: 7/9/2026, Latest version: 1.96.1
End of life: 5/28/2026, Latest version: 1.95.0
End of life: 4/16/2026, Latest version: 1.94.1
The gix-transport crate prior to the patched version 0.36.1 would allow attackers to use malicious ssh clone URLs to pass arbitrary arguments to the ssh program, leading to arbitrary code execution.
PoC: gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'
This will launch a calculator on OSX.
See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in git.
Thanks for vin01 for disclosing this issue.
In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock.
The processlock crate 0.1.0 for Rust allows data races in unlock.
In the memorypages crate 0.1.0 for Rust, division by zero can occur.
In groupnumber in the scsir crate 0.2.0 for Rust, there can be an overflow because a hardware device may expect a small number of bits (e.g., 5 bits) for group number.
End of life: 3/6/2026, Latest version: 1.93.1
Rust is a programming language. The Rust Security Response WG was notified that the Rust standard library prior to version 1.77.2 did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command. An attacker able to control the arguments passed to the spawned process could execute arbitrary shell commands by bypassing the escaping. The severity of this vulnerability is critical for those who invoke batch files on Windows with untrusted arguments. No other platform or use is affected.
The Command::arg and Command::args APIs state in their documentation that the arguments will be passed to the spawned process as-is, regardless of the content of the arguments, and will not be evaluated by a shell. This means it should be safe to pass untrusted input as an argument.
On Windows, the implementation of this is more complex than other platforms, because the Windows API only provides a single string containing all the arguments to the spawned process, and it's up to the spawned process to split them. Most programs use the standard C run-time argv, which in practice results in a mostly consistent way arguments are splitted.
One exception though is cmd.exe (used among other things to execute batch files), which has its own argument splitting logic. That forces the standard library to implement custom escaping for arguments passed to batch files. Unfortunately it was reported that our escaping logic was not thorough enough, and it was possible to pass malicious arguments that would result in arbitrary shell execution.
Due to the complexity of cmd.exe, we didn't identify a solution that would correctly escape arguments in all cases. To maintain our API guarantees, we improved the robustness of the escaping code, and changed the Command API to return an InvalidInput error when it cannot safely escape an argument. This error will be emitted when spawning the process.
The fix is included in Rust 1.77.2. Note that the new escaping logic for batch files errs on the conservative side, and could reject valid arguments. Those who implement the escaping themselves or only handle trusted inputs on Windows can also use the CommandExt::rawarg method to bypass the standard library's escaping logic.
On Monday, 29 December 2025 at 02:36, Demi Marie Obenour <demiobenour () gmail com> wrote: In light of the recent GnuPG vulnerabilities, I remembered that OpenPGP is almost never the right choice. CMS/PKCS#7 isn't any better, and X.509 is also bad except that its extremely wide deployment in TLS keeps it alive.
See https://www.latacora/com/blog/2019/07/16/the-pgp-problem/
and https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/. OpenBSD has signify[1] and the article "Securing OpenBSD From Us To You" by the main author is worth reading. Having been a loyal GnuPG user for long years, these vulnerabilities made me reconsider my approach to signing yet again. This time, though, I decided to act on it. I wrote a clean Rust implementation of signify and called it signify-rs[3]. It uses the same license (ISC) as the reference implementation. Code is free of unsafes and arithmetic side effects. No proc macros are used in the code or any dependencies making it static-linking friendly. It's fairly portable and passes tests on FreeBSD, NetBSD, Linux and Windows.
My initial goal is to switch signing Syd binary releases from gpg to signify. Next intention is to consider signing package manifests on Exherbo Linux distribution with it. If my memory serves me right, Gentoo Linux and Portage has support for GPG signed manifests and it has been a longstanding issue in Exherbo Linux how we want to do manifests. Current consensus is to use thin package manifests on a best-effort basis because we lack the developer time to go all in. Thin manifests store a single checksum and package size of the relevant package distfiles. My goal/dream is to integrate signify into this workflow and start signing thin manifests using signify.
Sharing is caring, so here is the git[5] and CI[6]. CI saves static-linked signify binaries as build artifacts which gives an option to quickly test. Enjoy.
Finally, my contribution is the "keyring" feature. When built with this feature on Linux, keyrings(7) support is compiled in. This adds a "-k <key-id>" argument to the subcommands -G(enerate) and -S(ign) when the user may submit a 32-bit key ID rather than inputting the passphrase manually with a prompt.
[1]: https://man.openbsd.org/signify [2]: https://www.openbsd.org/papers/bsdcan-signify.html [3]: https://crates.io/crates/signify-rs [4]: https://www.kepstin.ca/blog/manifest-generation-in-exherbo/ [5]: https://git.sr.ht/~alip/signify [6]: https://builds.sr.ht/~alip/signify -- Sincerely, Demi Marie Obenour (she/her/hers) Best regards, Ali Polatel
End of life: 1/22/2026, Latest version: 1.92.0
End of life: 12/11/2025, Latest version: 1.91.1
Starting from Rust 1.87.0 and before Rust 1.89.0, the tier 3 Cygwin target (x8664-pc-cygwin) didn't correctly handle path separators, causing the standard library's Path API to ignore path components separated by backslashes. Due to this, programs compiled for Cygwin that validate paths could misbehave, potentially allowing path traversal attacks or malicious filesystem operations.
Rust 1.89.0 fixes the issue by handling both Win32 and Unix style paths in the standard library for the Cygwin target.
While we assess the severity of this vulnerability as "medium", please note that the tier 3 Cygwin compilation target is only available when building it from source: no pre-built binaries are distributed by the Rust project, and it cannot be installed through Rustup. Unless you manually compiled the x8664-pc-cygwin target you are not affected by this vulnerability. Users of the tier 1 MinGW target (x8664-pc-windows-gnu) are also explicitly not affected.
End of life: 10/30/2025, Latest version: 1.90.0
An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Null pointer dereference vulnerability in the dump() method allows an attacker to cause a denial of service. The vulnerability exists because the method fails to check the return value of avfiltergraphdump() for NULL, leading to a crash if the underlying memory allocation fails.
An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Null pointer dereference vulnerability in the name() method allows an attacker to cause a denial of service. The vulnerability exists because the method fails to check for a NULL return value from the avgetsamplefmtname() C function, which can be triggered by providing an unrecognized sample format.
An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Integer overflow and invalid input vulnerability in the cached method allows an attacker to cause a denial of service or potentially execute arbitrary code. The vulnerability occurs when dimension parameters are zero or exceed i32::MAX, leading to an unchecked cast that violates the underlying C function's preconditions and triggers undefined behavior.