RUSTSEC-2026-0218 json
`Enum` trait allows type confusion when manually implemented
published 3mo ago modified 3mo ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
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`:
```rust 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](https://codeberg.org/sugar700/enum-map/commit/7a8b8154323d426415a10accf104cd05c394cda9) by adding a `Value = V` bound to the `Array` type in the `Enum` trait.
Patch / fix
- crates.io enum-map 3.1.0
Is RUSTSEC-2026-0218 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | enum-map | >=3.0.0-0.gat.0, <3.1.0 |
3.1.0 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.