RUSTSEC-2026-0432
Vulnerability from osv_rustsec – Published: 2026-10-31 12:00 – Updated: 2026-11-02 11:17 – Source websitecodeq 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.
| URL | Type | |
|---|---|---|
{
"affected": [
{
"database_specific": {
"categories": [
"denial-of-service"
],
"cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "codeq",
"purl": "pkg:cargo/codeq"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "0.6.3"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [],
"database_specific": {
"license": "CC0-1.0"
},
"details": "`codeq` is a serialization library whose `Decode` trait reads length-prefixed values. For `String` and `Vec\u003cu8\u003e`, 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).\n\nThe affected path, in `src/codec/impls/string_impl.rs`:\n\n```rust\nimpl Decode for String {\n fn decode\u003cR: io::Read\u003e(mut r: R) -\u003e Result\u003cSelf, io::Error\u003e {\n let len = r.read_u32::\u003cBigEndian\u003e()? as usize;\n let mut buf = vec![0; len]; // allocates `len` bytes up front\n r.read_exact(\u0026mut buf)?; \n String::from_utf8(buf).map_err(|e| io::Error::new(io::ErrorKind::InvalidData, e))\n }\n}\n```\n\nAny 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.\n\n## Remediation\n\nFixed 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 \u003e= 0.6.3`.",
"id": "RUSTSEC-2026-0432",
"modified": "2026-11-02T11:17:24Z",
"published": "2026-10-31T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/codeq"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0432.html"
},
{
"type": "REPORT",
"url": "https://github.com/drmingdrmer/codeq/issues/4"
}
],
"related": [],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "`codeq`: decoding untrusted input can allocate memory from an unchecked length prefix (denial of service)"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.