RUSTSEC-2026-0218: `Enum` trait allows type confusion when manually implemented

What to do

1. See which version you have: cargo tree -i enum-map (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p enum-map. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example enum-map = "3.1.0") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Affected versions of this crate did not require the element type of the Array associated type in the Enum trait to match the array's generic parameter V.

This can result in type confusion, and consequently memory corruption, when a manual Enum implementation declares an Array<V> whose elements are not actually of type V:

struct IntentionallyWrong;

impl Enum for IntentionallyWrong {
    type Array<V> = [String; 4];

    fn from_usize(_: usize) -> Self {
        IntentionallyWrong
    }

    fn into_usize(self) -> usize {
        0
    }
}

enum_map! { IntentionallyWrong => 42 };

The flaw was corrected in commit 7a8b815432 by adding a Value = V bound to the Array type in the Enum trait.

References

• Package: crates.io/crates/enum-map
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0218.html
• Web: codeberg.org/sugar700/enum-map/src/branch/master/CHANGELOG.md#version-310
• Report: github.com/rustsec/advisory-db/issues/3060

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for enum-map

• UnsoundRUSTSEC-2022-0010 · 2022-02-17enum_map macro can cause UB when `Enum` trait is incorrectly implemented

Full security history of enum-map