Announcing Rust 1.96.0 | Rust Blog

Rust Blog

Rust
Install
Learn
Tools
Governance
Community
🖌

Light
Dark
System

Announcing Rust 1.96.0

May 28, 2026 · The Rust Release Team

The Rust team is happy to announce a new version of Rust, 1.96.0. Rust is a programming language empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, you can get 1.96.0 with:
$ rustup update stable
If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.96.0.
If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.96.0 stable

New Range* types
Many users expect Range and related core::ops types to be Copy, but this is not the case: they implement Iterator directly, and it is a footgun to implement both Iterator and Copy on the same type so this has been avoided. RFC3550 proposed a set of replacement range types that implement IntoIterator rather than Iterator, meaning they can also be Copy. The standard library portion of that RFC is now stable, introducing:

core::range::Range
core::range::RangeFrom
core::range::RangeInclusive
Associated iterators

A Rust version in the near future will also add core::range::RangeFull and core::range::RangeTo as re-exports from core::ops (these do not implement Iterator and already implement Copy), and core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.
With these stabilizations, it is now possible to store slice accessors in Copy types without splitting start and end:
use core::range::Range;

#[derive(Clone, Copy)]
pub struct Span(Range<usize>);

impl Span {
pub fn of(self, s: &str) -> &str {
&s[self.0]
}
}
The new RangeInclusive also makes its fields public, unlike the legacy version which avoided exposing the exhausted iterator state. This isn't a concern with the new type since it must be converted to begin iteration.
Library authors should consider making use of impl RangeBounds in public API, which accepts both legacy and new range types. If a concrete type is needed, prefer using new ranges as this will eventually become the default.

Assert matching patterns
The new macros assert_matches! and debug_assert_matches! check that a value matches a given pattern, panicking with a Debug representation of the value otherwise. These are essentially the same as assert!(matches!(..)) and debug_assert!(matches!(..)), but the printed value improves the possibility of diagnosing the failure.
These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.
use core::assert_matches;

/// [Random Number](https://xkcd.com/221/)
fn get_random_number() -> u32 {
// chosen by a fair dice roll.
// guaranteed to be random.
4
}

fn main() {
assert_matches!(get_random_number(), 1..=6);
}
Changes to WebAssembly targets
WebAssembly targets no longer pass --allow-undefined to the linker which means that undefined symbols when linking are now a linker error instead of being converted to WebAssembly imports from the "env" module. This change prevents modules from linking unless all linking-related symbols are defined to catch bugs earlier and prevent accidental issues with symbol naming or similar.
Undefined linking-related symbols are often indicative of build-time related bugs or misconfiguration. If, however, the old behavior is intended then it can be re-enabled with RUSTFLAGS=-Clink-arg=--allow-undefined or by editing the source code and using #[link(wasm_import_module = "env")] on the block defining the symbol.
This change was previously announced on this blog, and now takes effect in Rust 1.96.

Stabilized APIs

assert_matches!
debug_assert_matches!
From<T> for AssertUnwindSafe<T>
From<T> for LazyCell<T, F>
From<T> for LazyLock<T, F>
core::range::RangeToInclusive
core::range::RangeToInclusiveIter
core::range::RangeFrom
core::range::RangeFromIter
core::range::Range
core::range::RangeIter

Two Cargo advisories
Rust 1.96 contains fixes for two vulnerabilities for users of third-party registries.

CVE-2026-5223 is a medium severity vulnerability regarding extraction of crate tarballs with symlinks.

CVE-2026-5222 is a low severity vulnerability regarding authentication with normalized URLs.

Users of crates.io are not affected by either vulnerability.

Other changes
Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.96.0
Many people came together to create Rust 1.96.0. We couldn't have done it without all of you. Thanks!

Get help!

Documentation
Contact the Rust Team

Terms and policies

Code of Conduct
Licenses
Logo Policy and Media Guide
Security Disclosures
All Policies

Social

RSS

Main Blog
"Inside Rust" Blog

Maintained by the Rust Team. See a typo?
Send a fix here!

The Rust team announced the release of Rust version 1.96.0, focusing on stabilizing new features, clarifying range types in the standard library, and implementing changes related to WebAssembly targets and security fixes.

A significant update involves the introduction of new range types, such as core::range::Range, core::range::RangeFrom, and core::range::RangeInclusive. This change addresses a design consideration where older core::ops types were expected to be Copy, but this conflicted with their implementation of Iterator. To resolve this conflict, the Rust team adopted RFC3550, proposing replacement range types that implement IntoIterator rather than Iterator, allowing these types to be Copy. This stabilization allows library authors to store slice accessors within Copy types without needing separate start and end indices, as demonstrated by the structure of Span types. The release also indicates future planned additions, including core::range::RangeFull and core::range::RangeTo as re-exports, alongside the establishment of core::range::legacy as the home for current ranges. Furthermore, library authors are advised to consider implementing the RangeBounds trait in their public APIs, favoring the new range types for concrete type usage.

The release also introduces new assertion macros, assert_matches! and debug_assert_matches!. These macros function similarly to assert!(matches!(..)) and debug_assert!(matches!(..)) but enhance debugging by providing a more descriptive representation of the value upon a failure. Because these macros would conflict with popular third-party crates, they are not placed in the standard prelude; instead, they must be manually imported from core or std.

Changes were implemented regarding WebAssembly targets, where the linker now enforces stricter rules by rejecting the use of the --allow-undefined flag. This change prevents undefined symbols from being converted to WebAssembly imports from the "env" module, forcing linking-related symbols to be explicitly defined, which helps catch build-time errors earlier.

Several APIs have been stabilized in this version, including the new assertion macros, trait implementations like From<T> for AssertUnwindSafe<T>, LazyCell<T, F>, and LazyLock<T, F>, and the core range types. In addition to the structural changes, Rust 1.96.0 includes fixes for two security vulnerabilities, CVE-2026-5223 and CVE-2026-5222, which pertain to vulnerabilities in third-party registry tarball extraction and normalized URL authentication, respectively. These fixes do not affect users of crates.io directly.