VulnerabilityRUSTSEC-2026-0342 · quinn-proto
RUSTSEC-2026-0342: Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-proto
Short answerA security vulnerability in the quinn-proto crate: Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-proto. No severity score was published. Fixed in 0.11.17: update to a fixed version.
| Crate | quinn-proto |
|---|---|
| Type | Vulnerability (denial-of-service) |
| Affected versions | From 0.5.0 before 0.11.17. |
| Fixed in | 0.11.17 |
| Severity | not scored |
| Published | 2026-08-17 |
| Last changed | 2026-10-12 |
| Also known as | GHSA-2hv7-gw8g-gpq5 |
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
quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.
DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.
The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.
The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.
Thanks to @alexpyattaev for reporting this issue.
References
- Package: crates.io/crates/quinn-proto
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0342.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
- Vulnerability HighRUSTSEC-2026-0341 · 2026-08-17Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed
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?