Rust 1.96 Ships Copy-Friendly Range Types, Stabilizes assert_matches!, and Patches Two Cargo CVEs

Overview

Rust 1.96.0 shipped on May 28, 2026, delivering one of the language’s most requested ergonomics improvements — Copy-implementing range types — alongside the stabilization of pattern-matching assertion macros, a stricter default for WebAssembly linking, and security fixes for two Cargo vulnerabilities that affect users of third-party registries, according to the Rust team’s release announcement. The release follows Rust 1.95 and keeps pace with the language’s six-week cadence.

Copy Range Types: Resolving a Longstanding Limitation

The headline change in 1.96 is the stabilization of replacement range types under core::range, defined in RFC 3550. The existing range types in core::ops — such as Range, RangeFrom, and RangeInclusive — implement Iterator directly, which prevents them from being Copy. This limitation frustrated library authors who needed to store range values in copyable structs without triggering move semantics.

As the Rust team explains, “It is a footgun to implement both Iterator and Copy on the same type,” which motivated the design of the replacement types. The new core::range::Range, core::range::RangeFrom, and core::range::RangeInclusive implement IntoIterator instead of Iterator, freeing them to also implement Copy. The new RangeInclusive additionally exposes public fields, unlike the legacy version.

Migration is designed to be gradual. According to Linuxiac, “range syntax like 0..1 still produces the legacy range types” for now; the transition to core::range types will happen in a future edition. Library authors writing public APIs are advised to use impl RangeBounds to remain compatible with both old and new range types. Future releases will add RangeFull, RangeTo, and legacy::* variants to complete the set, according to the release announcement.

assert_matches! Stabilized — With a Deliberate Opt-In

Rust 1.96 also stabilizes assert_matches! and debug_assert_matches!, two macros that check whether a value matches a given pattern and emit a Debug representation of the value on failure. Unlike most standard library additions, these macros were intentionally kept out of the standard prelude to avoid name collisions with popular third-party crates that already provide macros with the same names, according to the Rust blog. Developers must manually import them from core or std before use.

The deliberate opt-in drew positive attention in the Rust community. On LWN.net, subscriber tialaramex described the decision as consistent with building “a future you can be proud of, rather than one where everything needs a long list of caveats.”

WebAssembly Linking Made Stricter

A behavioral change affecting WebAssembly developers takes effect in 1.96: Wasm targets no longer pass --allow-undefined to the linker. According to the Rust team, “Undefined symbols when linking are now a linker error instead of being converted to WebAssembly imports.” Projects that relied on the previous behavior can restore it by setting RUSTFLAGS=-Clink-arg=--allow-undefined or by annotating imports with #[link(wasm_import_module = "env")] in source code.

Two Cargo Security Fixes

Rust 1.96 bundles patches for two Cargo vulnerabilities. Both affect only users of third-party registries; according to the Rust team, “Users of crates.io are not affected by either vulnerability.”

CVE-2026-5223 (Medium): Cargo incorrectly handled symlinks in crate tarballs downloaded from third-party registries. According to the security advisory, a malicious crate could exploit this to override source code of other crates from the same registry by extracting files one level below the target crate’s cache directory. The fix updates Cargo to reject extracting any symlink within crate tarballs. The practical impact is limited because, as the advisory notes, “Cargo never added symlinks when running cargo package or cargo publish,” meaning legitimate crates on crates.io would not trigger the issue. Users of third-party registries who cannot upgrade immediately should audit their registries for symlinks.

CVE-2026-5222 (Low): Cargo incorrectly normalized URLs for third-party registries using the sparse index protocol, treating URLs with and without a .git suffix as identical — behavior inherited from git repository handling that does not apply to sparse indexes. The advisory states that all Cargo versions shipped between Rust 1.68, which stabilized sparse registries, and Rust 1.95 are affected. Exploitation requires an attacker to control a sparse index at a domain, publish crates to that registry, upload files to a .git variant of the domain, and have a victim download a malicious crate with cross-registry dependencies. The fix updates Cargo to strip the .git suffix only from registry URLs that use the git protocol. The vulnerability was reported by Christos Papakonstantinou through Rust’s security disclosure policy. No mitigations are available for older Cargo versions.

Additional Changes

Beyond the headline features, the changelog at releases.rs documents several further changes in 1.96:

• Ranges of NonZero integers can now be iterated directly.
• Expression metavariables can now be passed to cfg attributes in macros.
• never types now coerce consistently in tuple expressions.
• A regression in constants of type ManuallyDrop used as patterns — introduced in 1.94 — is fixed.
• The minimum supported external LLVM version rises to 21.
• Link relaxation is now enabled for LoongArch Linux targets.
• The riscv64gc-unknown-fuchsia target baseline is updated to RVA22 with vector support.
• s390x gains vector register support in inline assembly.
• Cargo gains the ability to specify both a git repository and an alternate registry simultaneously for a dependency.
• Rustdoc deprecation notes now render using standard documentation styling.

Several breaking changes take effect as well: Pin<Foo> unsize coercions are blocked when Foo does not implement Deref; the uninhabited_static lint becomes deny-by-default in dependencies; struct imports using {self as name} syntax are no longer permitted; and multiple export_name, link_name, or link_section attributes on the same item now give precedence to the first.

What We Don’t Know

• When a future Rust edition will transition the 0..1 range syntax to produce core::range types rather than legacy core::ops types.
• Whether assert_matches! will be added to the prelude in a future release once the ecosystem has migrated away from conflicting third-party crates.
• The full adoption timeline for the new RangeFull, RangeTo, and legacy::* range variants noted as planned for future releases.