Vulnerability HighRUSTSEC-2026-0343 · quinn-proto
RUSTSEC-2026-0343: Outgoing datagram buffer accounting can panic the sender in quinn-proto
Short answerA security vulnerability in the quinn-proto crate: Outgoing datagram buffer accounting can panic the sender in quinn-proto. High severity (CVSS 7.5). Fixed in 0.11.18: update to a fixed version.
| Crate | quinn-proto |
|---|---|
| Type | Vulnerability (denial-of-service) |
| Affected versions | From 0.11.17 before 0.11.18. |
| Fixed in | 0.11.18 |
| 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-09-14 |
| Last changed | 2026-10-12 |
| Also known as | GHSA-ppcp-v39w-8jq2 |
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
The limit on memory used to buffer outgoing datagrams, introduced in 0.11.17, subtracted an evicted datagram's size from the buffered byte counter twice when Datagrams::send was called with drop = true (as Connection::send_datagram in the quinn crate does) while the buffer was full. Under sustained eviction the counter drifts below its true value: debug builds panic with an integer underflow, while release builds wrap the counter, drain the whole queue, and then panic on a desynchronization check in a later send call. In quinn, this panic occurs while the connection lock is held, poisoning it and causing a double panic (and thus an abort) when the connection is dropped.
This can be triggered without a malicious peer, by an application that sends a burst of datagrams and then idles. It can also be triggered by a peer that keeps the connection alive with PING frames while withholding acknowledgements, so that the sender's congestion window stays closed and the outgoing queue never drains. Applications that use send_datagram_wait are not affected.
Only 0.11.17 is affected; the flaw was corrected in 0.11.18 by removing the redundant subtraction.
Thanks to @alexpyattaev for reporting and @vcarus for fixing this issue.
References
- Package: crates.io/crates/quinn-proto
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0343.html
- Web: github.com/quinn-rs/quinn/pull/2806
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?