RUSTSEC-2026-0432

Dashboard / Vulnerabilities / RUSTSEC-2026-0432

RUSTSEC-2026-0432

Summary: `codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)

Details: `codeq` is a serialization library whose `Decode` trait reads length-prefixed values. For `String` and `Vec<u8>`, the length-prefixed `Decode` implementations read a 4-byte big-endian length and allocate a buffer of that size **before** reading the payload. Because the declared length is taken straight from the input with no upper bound and no cross-check against the bytes actually available, a tiny input can force an allocation of up to ~4 GiB. Code that decodes untrusted data through `codeq` can therefore be made to spike memory use and be OOM-killed (CWE-400, uncontrolled resource consumption). The affected path, in `src/codec/impls/string_impl.rs`: ```rust impl Decode for String { fn decode<R: io::Read>(mut r: R) -> Result<Self, io::Error> { let len = r.read_u32::<BigEndian>()? as usize; let mut buf = vec![0; len]; // allocates `len` bytes up front r.read_exact(&mut buf)?; String::from_utf8(buf).map_err(|e| io::Error::new(io::ErrorKind::InvalidData, e)) } } ``` Any code that decodes attacker-controlled bytes through `codeq` can be forcedcto allocate up to ~4 GiB per `decode` call from a 4-byte length prefix. On a service decoding untrusted input this is a cheap denial of service (crash / OOM-kill). The practical severity depends on how the embedding wires `codeq` to untrusted bytes. ## Remediation Fixed in `0.6.3`, which grows the decode buffers as payload bytes actually arrive instead of pre-allocating the full declared length (commit `9f15313`, "fix: codec: grow decode buffers as payload bytes arrive"). Upgrade to `codeq >= 0.6.3`.

References: https://crates.io/crates/codeq, https://rustsec.org/advisories/RUSTSEC-2026-0432.html, https://github.com/drmingdrmer/codeq/issues/4