VulnerabilityRUSTSEC-2026-0338 · quinn-proto
RUSTSEC-2026-0338: Remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads
Short answerA security vulnerability in the quinn-proto crate: Remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads. No severity score was published. Fixed in 0.11.18: update to a fixed version.
| Crate | quinn-proto |
|---|---|
| Type | Vulnerability (denial-of-service) |
| Affected versions | From 0.7.0 before 0.11.18. |
| Fixed in | 0.11.18 |
| Severity | not scored |
| Published | 2026-09-14 |
| Last changed | 2026-10-12 |
| Also known as | GHSA-465w-v9q3-7j98 |
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.18") 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
When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.
A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.
The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.
Thanks to Otto Hermann (@ojhermann) for reporting this issue.
References
- Package: crates.io/crates/quinn-proto
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0338.html
- Web: github.com/quinn-rs/quinn/pull/2868
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-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
- Vulnerability HighRUSTSEC-2026-0341 · 2026-08-17Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed
- 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?