RustSec flags emap bug that can return freed memory through safe APIs
RustSec’s emap advisory says a routine keys iterator can expose freed memory through safe APIs, with no patched release yet.

A routine keys iterator in emap turned into a path to freed memory, and RustSec has now put a number on it: RUSTSEC-2026-0128, issued May 13 and reported on May 2, flagged the crate as INFO, Unsound, with memory-corruption keywords for double-free and use-after-free. There is no patched version yet, which leaves downstream users with a blunt choice: avoid the crate or audit every code path that touches its map and iterator APIs.
The break starts in Keys::next. RustSec says that method uses ptr::read to move an Option<V> out by value, and when V is a non-Copy type such as String, that move drops the value while leaving a dangling slot behind in the map’s storage. A later call to Map::get on the same key can then hand back a reference to memory that has already been freed. The dangerous part is that the caller does not need unsafe code to reach it. The advisory says the path runs through Map::keys, Keys::next, and Map::get, all safe public APIs. Under Miri, the freed slot shows up as a dangling pointer, which is exactly the failure mode Rust’s ownership model is meant to rule out.

That makes emap a cautionary case for crate authors who treat small utility collections as too mundane to audit closely. On docs.rs, emap describes itself as an integer-keyed map with fixed capacity and performance claims centered on sequential usize keys, even calling itself the fastest map possible in Rust. That pitch helps explain why an unsoundness in its internals matters beyond a single dependency. It is the kind of crate that gets copied into bigger systems, where a safe-looking iterator can become the hidden edge of a memory-safety bug.
The advisory also fits a pattern around emap’s storage and iteration logic. Earlier issue #150 said Map::drop leaked stored values, while issue #125 discussed next_key() and the crate’s iterator and performance tradeoffs. This latest report lands upstream in GitHub issue #168 in yegor256/emap, where the fix will have to prove that the iterator no longer hands out access to dead storage.

RustSec’s reach is what makes the warning hard to ignore. Its advisories feed cargo-audit, cargo-deny, Trivy, Dependabot, and the GitHub Advisory Database, and RustSec also exports to OSV. Once an entry like this lands, it can surface across dependency scans quickly. emap’s safe-looking iterator was always doing more than its name suggested, and now the advisory makes the danger plain: a normal keys walk can cross straight into double-free and use-after-free territory.
Know something we missed? Have a correction or additional information?
Submit a Tip
