wee_alloc is Unmaintained

Two of the maintainers have indicated that the crate may not be maintained. The crate has open issues including memory leaks and may not be suitable for production use. It may be best to switch to the default Rust standard allocator on wasm32 targets. Last release seems to have been three years...

Out-of-bounds write in nix::unistd::getgrouplist

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 functi...

Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss

When decoding chunk sizes that are too large, hyper's code would encounter an integer overflow. Depending on the situation, this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack. To be vulnerable, you must be using hyper for any HTTP/1 purpose,...

Multiple memory safety issues

Affected versions contain multiple memory safety issues, such as: - Setting a multi label type where an image doesn't exist would lead to a NULL pointer dereference. - Setting a window icon using a non-raster image which FLTK rasterizes lazily would lead to a NULL dereference. - Pixmap constructo...

Deserialization functions pass uninitialized memory to user-provided Read

Affected versions of this crate passed an uninitialized buffer to a user-provided Read instance in: deserializebinary deserializestring deserializeextensionothers deserializestringprimitive This can result in safe Read implementations reading from the uninitialized buffer leading to undefined...

panic in user-provided `Endian` impl triggers double drop of T

Affected versions of the crate does not guard against panic from user-provided impl of Endian trait, which is a safe trait that users can implement. If a user-provided implementation of the Endian trait panics, double-drop is triggered due to the duplicated ownership of T created by ptr::read...

UsbContext trait did not require implementers to be Send and Sync.

Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The...

nanorand 0.5.0 - RNGs failed to generate properly for non-64-bit numbers

In versions of nanorand prior to 0.5.1, RandomGen implementations for standard unsigned integers could fail to properly generate numbers, due to using bit-shifting to truncate a 64-bit number, rather than just an as conversion. This often manifested as RNGs returning nothing but 0, including the...

MPMCConsumer/Producer allows sending non-Send type across threads

Affected versions of this crate unconditionally implemented Sync and Send traits for MPMCConsumer and MPMCProducer types. This allows users to send types that do not implement Send trait across thread boundaries, which can cause a data race. The flaw was corrected in the 2.0.1 release by adding T...

Singleton lacks bounds on Send and Sync.

Singleton is meant to be a static object that can be initialized lazily. In order to satisfy the requirement that static items must implement Sync, Singleton implemented both Sync and Send unconditionally. This allows for a bug where non-Sync types such as Cell can be used in singletons and cause...

Data race and memory safety issue in `Index`

The appendix crate implements a key-value mapping data structure called Index that is stored on disk. The crate allows for any type to inhabit the generic K and V type parameters and implements Send and Sync for them unconditionally. Using a type that is not marked as Send or Sync with Index can...

`LockWeak<T>` allows to create data race to `T`.

In the affected versions of this crate, LockWeak unconditionally implemented Send with no trait bounds on T. LockWeak doesn't own T and only provides &T. This allows concurrent access to a non-Sync T, which can cause undefined behavior like data races...

Unsafe Send implementation in Atom allows data races

The atom crate contains a security issue revolving around its implementation of the Send trait. It incorrectly allows any arbitrary type to be sent across threads potentially leading to use-after-free issues through memory races...

Multiple security issues including data race, buffer overflow, and uninitialized memory drop

arr crate contains multiple security issues. Specifically, 1. It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary. 2. Index and IndexMut implementation does not check the array bound. 3. Array::newfromtemplate drops uninitialized memo...

Matrix::new() drops uninitialized memory

Matrix::new internally calls Matrix::fillwith which uses ptr = value pattern to initialize the buffer. This pattern assumes that there is an initialized struct at the address and drops it, which results in dropping of uninitialized struct...

Chunk API does not respect align requirement

Chunk API does not respect the align requirement of types. Unaligned reference can be created with the API, which is an undefined behavior...

Allows viewing and modifying arbitrary structs as bytes

Affected versions of rgb crate allow viewing and modifying data of any type T wrapped in RGB as bytes, and do not correctly constrain RGB and other wrapper structures to the types for which it is safe to do so. Safety violation possible for a type wrapped in RGB and similar wrapper structures: If...

rio allows a use-after-free buffer access when a future is leaked

When a rio::Completion is leaked, its drop code will not run. The drop code is responsible for waiting until the kernel completes the I/O operation into, or out of, the buffer borrowed by rio::Completion. Leaking the struct will allow one to access and/or drop the buffer, which can lead to a...

bigint is unmaintained, use uint instead

The bigint crate is not maintained any more and contains several known bugs including a soundness bug; use uint instead...

CBox API allows to de-reference raw pointers without `unsafe` code

CBox and CSemiBox are part of the public API of the cbox crate and they allow to create smart pointers from raw pointers and de-reference them without the need of unsafe code...

tiberius is unmaintained

The author of tiberius has archived the GitHub repository and left the following note: I do not have the time to overhaul the library and do not intend to further maintain the 0.3 version relying on the old futures ecosystem. Suggested alternatives are: - odbc - sqlx forthcoming...

HeaderMap::Drain API is unsound

Affected versions of this crate incorrectly used raw pointer, which introduced unsoundness in its public safe API. Failing to drop the Drain struct causes double-free, and it is possible to violate Rust's alias rule and cause data race with Drain's Iterator implementation. The flaw was corrected ...

generichash::Digest::eq always return true

PartialEq implementation for generichash::Digest has compared itself to itself. Digest::eq always returns true and Digest::ne always returns false...

Incorrect implementation of the Streebog hash functions

Internal update-sigma function was implemented incorrectly and depending on debug-assertions it could've caused an incorrect result or panic for certain inputs...

typemap is Unmaintained

The maintainer seems unreachable. The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust. The last release seems to have been seven years ago. Possible Alternatives The below list has not been vetted in any way and may or may not contain...

HTTPS MitM vulnerability due to lack of hostname verification

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests. This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch. The problem was addressed by...

`pqcrypto-falcon` is unmaintained: upstream PQClean project being archived

This crate provides Rust bindings to the Falcon FN-DSA signature scheme via C implementations from PQClean. The PQClean project is being archived in or after July 2026 see PQClean/PQClean604, after which no further security patches or bug fixes will be applied to the upstream implementations. As ...

Reachable panic in certificate revocation list parsing

A panic was reachable when parsing certificate revocation lists via BorrowedCertRevocationList::fromder or OwnedCertRevocationList::fromder. This was the result of mishandling a syntactically valid empty BIT STRING appearing in the onlySomeReasons element of a IssuingDistributionPoint CRL...

Denial of Service via Stack Exhaustion

Impact 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,...

`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::nextback methods temporarily create an exclusive reference to the key when dereferencing the internal node pointer. This invalidates the shared pointer held by the...

rustls-pemfile is unmaintained

The rustls-pemfile crate is no longer maintained. The repository has been archived since August 2025, and users are encouraged to depend directly on the underlying PEM parsing code included in rustls-pki-types since 1.9.0. The latest version of rustls-pemfile is in fact a thin wrapper around the...

`tokio-tar` parses PAX extended headers incorrectly, allows file smuggling

The archive reader incorrectly handles PAX extended headers, when the ustar header incorrectly specifies zero size size=000000000000, while a PAX header specifies a non-zero size, tokio-tar::Archive is going to read the file content as tar entry header. This can be used by a tar file to present...

`tokio::io::ReadHalf<T>::unsplit` is Unsound

tokio::io::ReadHalf::unsplit can violate the Pin contract The soundness issue is described in the tokio/issues5372 Specific set of conditions needed to trigger an issue a !Unpin type in ReadHalf is unusual, combined with the difficulty of making any arbitrary use-after-free exploitable in Rust...

Post-Quantum Key Encapsulation Mechanism SIKE broken

Wouter Castryck and Thomas Decru presented an efficient key recovery attack on the SIDH protocol. As a result, the secret key of SIKEp751 can be recovered in a matter of hours. The SIKE and SIDH schemes will be removed from oqs 0.7.2. The affected schemes are the oqs::kem::Algorithm::Sike and...

Space bug in `clean_text`

An incorrect mapping from HTML specification to ASCII codes was used. Because HTML treats the Form Feed as whitespace, code like this has an injection bug: let html = format!"", cleantextusersuppliedstring; Applications are not affected if they quote their attributes, or if they don't use cleante...

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs: A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event: let sta...

Remote memory exhaustion in ckb

In the ckb sync protocol, SyncState maintains a HashMap called 'misbehavior' that keeps a score of a peer's violations of the protocol. This HashMap is keyed to PeerIndex an alias for SessionId, and entries are never removed from it. SessionId is an integer that increases monotonically with every...

libsecp256k1 allows overflowing signatures

libsecp256k1 accepts signatures whose R or S parameter is larger than the secp256k1 curve order, which differs from other implementations. This could lead to invalid signatures being verified. The error is resolved in 0.5.0 by adding a checkoverflow flag...

VecStorage Deserialize Allows Violation of Length Invariant

The Deserialize implementation for VecStorage did not maintain the invariant that the number of elements must equal nrows ncols. Deserialization of specially crafted inputs could allow memory access beyond allocation of the vector. This flaw was introduced in v0.11.0 086e6e due to the addition of...

`quinn` invalidly assumes the memory layout of std::net::SocketAddr

The quinn crate has assumed std::net::SocketAddrV4 and std::net::SocketAddrV6 have the same memory layout as the system C representation sockaddr. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the...

PartialReader passes uninitialized memory to user-provided Read

Affected versions of this crate passed an uniniitalized buffer to a user-provided Read instance in PartialReader::read. This can result in safe Read implementations reading from the uninitialized buffer leading to undefined behavior. The flaw was fixed in commit 39d62c6 by zero-initializing the...

panic safety: double drop or uninitialized drop of T upon panic

Affected versions of this crate did not guard against potential panics that may happen from user-provided functions T::default and T::drop. Panic within T::default leads to dropping uninitialized T, when it is invoked from common::Slice::::new. Panic within T::drop leads to double drop of T, when...

Reading on uninitialized buffer may cause UB ( `gfx_auxil::read_spirv()` )

Affected versions of this crate passes an uninitialized buffer to a user-provided Read implementation. Arbitrary Read implementations can read from the uninitialized buffer memory exposure and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory...

`Frame::copy_from_raw_parts` can lead to segfault without `unsafe`

fn Frame::copyfromrawparts is a safe API that can take a raw pointer and dereference it. It is possible to read arbitrary memory address with an arbitrarily fed pointer. This allows the safe API to access & read arbitrary address in memory. Feeding an invalid memory address pointer to the API may...

difference is unmaintained

The author of the difference crate is unresponsive. Maintained alternatives: - dissimilar - similar - treediff - diffus...

Async-h1 request smuggling possible with long unread bodies

This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications. If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at...

Unsound: can make `ARefss` contain a !Send, !Sync object.

ARefss is a type that is assumed to contain objects that are Send + Sync. In the affected versions of this crate, Send/Sync traits are unconditionally implemented for ARefss. By using the ARefss::map API, we can insert a !Send or !Sync object into ARefss. After that, it is possible to create a da...

Unexpected panic when decoding tokens

Prior to 0.10.0 it was possible to have both decoding functions panic unexpectedly, by supplying tokens with an incorrect base62 encoding. The documentation stated that an error should have been reported instead...

Send bound needed on T (for Send impl of `Bucket2`)

Affected versions of this crate unconditionally implements Send for Bucket2. This allows sending non-Send types to other threads. This can lead to data races when non Send types like Cell or Rc are contained inside Bucket2 and sent across thread boundaries. The data races can potentially lead to...

Slock<T> allows sending non-Send types across thread boundaries

Slock unconditionally implements Send/Sync. Affected versions of this crate allows sending non-Send types to other threads, which can lead to data races and memory corruption due to the data race...