GHSA-rxhx-9fj6-6h2m — enum-map
Fix: xfix/enum-map@b824e23GHSA-rxhx-9fj6-6h2m is a remote code execution vulnerability in enum-map. A fix is available for enum-map — see the affected versions and patch details below.
enum_map macro can cause UB when `Enum` trait is incorrectly implemented
Real-World Exposure
enum-mapReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Affected versions of this crate did not properly check the length of an enum when using enum_map! macro, trusting user-provided length.
When the LENGTH in the Enum trait does not match the array length in the EnumArray trait, this can result in the initialization of the enum map with uninitialized types, which in turn can allow an attacker to execute arbitrary code.
This problem can only occur with a manual implementation of the Enum trait, it will never occur for enums that use #[derive(Enum)].
Example code that triggers this vulnerability looks like this:
enum E {
A,
B,
C,
}
impl Enum for E {
const LENGTH: usize = 2;
fn from_usize(value: usize) -> E {
match value {
0 => E::A,
1 => E::B,
2 => E::C,
_ => unimplemented!(),
}
}
fn into_usize(self) -> usize {
self as usize
}
}
impl<V> EnumArray<V> for E {
type Array = [V; 3];
}
let _map: EnumMap<E, String> = enum_map! { _ => "Hello, world!".into() };
The flaw was corrected in commit b824e23 by putting LENGTH property on sealed trait for macro to read.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | enum-map | ≥ 2.0.0-2&&< 2.0.2 | 2.0.2cargo update -p enum-map --precise 2.0.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for enum-map, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update enum-map to 2.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rxhx-9fj6-6h2m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-rxhx-9fj6-6h2m in your dependencies?
Find it across crates.io, including transitive dependencies.