Vulnerability HighRUSTSEC-2026-0341 · quinn-proto
RUSTSEC-2026-0341: Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed
Short answerA security vulnerability in the quinn-proto crate: Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed. High severity (CVSS 7.5). Fixed in 0.11.17: update to a fixed version.
| Crate | quinn-proto |
|---|---|
| Type | Vulnerability (denial-of-service) |
| Affected versions | From 0.11.15 before 0.11.17. |
| Fixed in | 0.11.17 |
| Severity | High, CVSS 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| Published | 2026-08-17 |
| Last changed | 2026-10-12 |
| Also known as | GHSA-qfwj-vfxf-92j2 |
What to do
- See which version you have:
cargo tree -i quinn-proto(it also shows which of your dependencies pulls it in). - Update within your version requirement:
cargo update -p quinn-proto. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for examplequinn-proto = "0.11.17") or update the dependency that pulls it in. - Check again with
cargo audit, or paste your Cargo.lock into our Cargo.toml checker.
Details from the advisory
The 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.
References
- Package: crates.io/crates/quinn-proto
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0341.html
- Web: github.com/quinn-rs/quinn/pull/2790
From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.
Other advisories for quinn-proto
- Vulnerability HighRUSTSEC-2023-0063 · 2023-09-21Denial of service in Quinn servers
- Vulnerability HighRUSTSEC-2024-0373 · 2024-09-02`Endpoint::retry()` calls can lead to panicking
- VulnerabilityRUSTSEC-2026-0037 · 2026-03-09Denial of service in Quinn endpoints
- Vulnerability HighRUSTSEC-2026-0185 · 2026-06-22 Remote memory exhaustion in quinn-proto from unbounded out-of-order stream reassembly
- VulnerabilityRUSTSEC-2026-0338 · 2026-09-14Remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads
- VulnerabilityRUSTSEC-2026-0339 · 2026-08-17Unbounded growth of pending connection ID retirements in quinn-proto
- Vulnerability HighRUSTSEC-2026-0340 · 2026-09-14Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
- VulnerabilityRUSTSEC-2026-0342 · 2026-08-17Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-proto
Up next
Same cratequinn-proto: security historyEvery advisory for this crate, and whether it is safe to use today.Read it next →Did this answer your question?