RUSTSEC-2026-0235 json
Insufficient archive validation can cause out-of-bounds reads in archives containing Rc/Arc
published 5mo 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
Shared pointer validation keyed already-validated pointees by their address and type, but did not include pointer metadata. For unsized pointees, an archive could therefore contain multiple `Rc`, `Arc`, or weak pointers that shared a data address but used different metadata, such as different slice lengths.
Once the first pointer had been validated, later pointers to the same address skipped pointee validation. The safe checked `rkyv::access` API could consequently return a slice with a forged length, allowing safe indexing to read out of bounds. The same validation bypass was reachable through checked deserialization with `rkyv::from_bytes`.
Version 0.8.17 includes pointer metadata in shared pointer validation and rejects conflicting metadata. The 0.7 series is also affected but is no longer supported by upstream. Users who process untrusted archives should upgrade to 0.8.17 or later.
Patch / fix
Is RUSTSEC-2026-0235 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 | rkyv | >=0.7.0-pre.2, <0.8.17 |
0.8.17 |
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.