Every CVE Search/ Get API key

RUSTSEC-2026-0432

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

5.3 MediumFix available

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 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
codeq
crates.io
0.0.0-0 up to 0.6.3
0.6.3

History

History
RecordedChangedSources
first indexedOSV

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.

References

MoveEnter Open