RUSTSEC-2026-0341 (GHSA-QFWJ-VFXF-92J2)
Vulnerability from osv_rustsec – Published: 2026-08-17 12:00 – Updated: 2026-10-12 18:05 – Source websiteThe fix for RUSTSEC-2026-0185 in 0.11.15 added a cap on the number of chunks buffered by the
Assembler that reassembles out-of-order stream data. However, the cap was only checked inside
the branch that triggers defragmentation, which only runs when the estimated over-allocation
exceeds a threshold proportional to the amount of buffered data. Frames handled entirely by the
unordered-read deduplication loop returned before the check ran at all.
A peer sending one small gapped STREAM frame per packet (for example, 6-byte frames separated by
1-byte gaps) keeps the per-chunk overhead below the defragmentation threshold, so the cap is never
evaluated and the chunk count grows until stream-level flow control stops the peer. With the default
TransportConfig (100 concurrent unidirectional streams and a 1.25 MB stream receive window), a
remote, unauthenticated peer can pin roughly 3 GB of receiver memory using about 125 MB of accounted
stream data. The memory is not reclaimed until the affected streams or the connection are closed.
The flaw was corrected in 0.11.17 by checking the chunk count after every insert (including in the unordered deduplication loop) and compacting the buffer once it passes a watermark above the cap. A stream is rejected once compaction can no longer bring the chunk count back under the cap.
Versions before 0.11.15 are affected by the original, broader issue described in RUSTSEC-2026-0185.
Thanks to Otto Hermann (@ojhermann) for reporting and fixing this issue.
{
"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:H",
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "quinn-proto",
"purl": "pkg:cargo/quinn-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0.11.15"
},
{
"fixed": "0.11.17"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-qfwj-vfxf-92j2"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "The fix for RUSTSEC-2026-0185 in 0.11.15 added a cap on the number of chunks buffered by the\n`Assembler` that reassembles out-of-order stream data. However, the cap was only checked inside\nthe branch that triggers defragmentation, which only runs when the estimated over-allocation\nexceeds a threshold proportional to the amount of buffered data. Frames handled entirely by the\nunordered-read deduplication loop returned before the check ran at all.\n\nA peer sending one small gapped STREAM frame per packet (for example, 6-byte frames separated by\n1-byte gaps) keeps the per-chunk overhead below the defragmentation threshold, so the cap is never\nevaluated and the chunk count grows until stream-level flow control stops the peer. With the default\n`TransportConfig` (100 concurrent unidirectional streams and a 1.25 MB stream receive window), a\nremote, unauthenticated peer can pin roughly 3 GB of receiver memory using about 125 MB of accounted\nstream data. The memory is not reclaimed until the affected streams or the connection are closed.\n\nThe flaw was corrected in 0.11.17 by checking the chunk count after every insert (including in the\nunordered deduplication loop) and compacting the buffer once it passes a watermark above the cap.\nA stream is rejected once compaction can no longer bring the chunk count back under the cap.\n\nVersions before 0.11.15 are affected by the original, broader issue described in RUSTSEC-2026-0185.\n\nThanks to Otto Hermann ([@ojhermann](https://github.com/ojhermann)) for reporting and fixing\nthis issue.",
"id": "RUSTSEC-2026-0341",
"modified": "2026-10-12T18:05:20Z",
"published": "2026-08-17T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/quinn-proto"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0341.html"
},
{
"type": "WEB",
"url": "https://github.com/quinn-rs/quinn/pull/2790"
}
],
"related": [
"RUSTSEC-2026-0185"
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed"
}
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.
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.