Vulnerabilities

RUSTSEC-2026-0007

Integer overflow in BytesMut::reserve

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.

Warnings

RUSTSEC-2024-0388

derivative is unmaintained; consider using an alternative

The derivative crate is no longer maintained.
Consider using any alternative, for instance:

• derive_more
• derive-where
• educe

RUSTSEC-2024-0436

paste - no longer maintained

The creator of the crate paste has stated in the README.md
that this project is not longer maintained as well as archived the repository

Possible Alternative(s)

• pastey: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
• with_builtin_macros: crate providing a superset of paste's functionality including general macro_rules! eager expansions and concat!/concat_idents! macros

RUSTSEC-2026-0012

Unsoundness in opt-in ARMv8 assembly backend for keccak

Summary

The asm! block enabled by the off-by-default asm feature, when enabled on ARMv8 targets, misspecified the operand
type for all of its operands, using in for pointers and values which were subsequently mutated by operations performed
within the assembly block.

Impact

It's unclear what practical impact, if any, this actually had. Incorrect operand types are technically undefined
behavior, however changing them had no actual impact on the generated assembly for these targets. The possibility still
exists that it may lead to potential memory safety or other issues on hypothetical future versions of rustc.

Mitigation

The operand types were changed from in to inout, and the impacted versions of the keccak crate were yanked.

RUSTSEC-2026-0002

IterMut violates Stacked Borrows by invalidating internal pointer

Affected versions of this crate contain a soundness issue in the IterMut
iterator implementation. The IterMut::next and IterMut::next_back
methods temporarily create an exclusive reference to the key when
dereferencing the internal node pointer.

This invalidates the shared pointer held by the internal HashMap,
violating Stacked Borrows rules.

Crate keccak is yanked

No extra details provided.