RUSTSEC-2026-0432
`codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)
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:
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
What each source reports
OSV Score used
5.3
`codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)
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:
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.
- Record
RUSTSEC-2026-0432- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
codeqcrates.io |
0.0.0-0 up to 0.6.3 | 0.6.3 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
RUSTSEC-2026-0432 is a medium vulnerability (CVSS 5.3) in codeq, published October 31, 2026. No source lists public exploit code. Fixed in codeq 0.6.3.