Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When sending ACK_FREQUENCY frames is enabled through `TransportConfig::ack_frequency_config(Some(..))`, the peer's transport parameters could cause `AckFrequencyState::candidate_max_ack_delay` to call `Duration::clamp` with a minimum greater than its maximum, which panics. For example, a peer advertising a `min_ack_delay` of 100,000 microseconds and a `max_ack_delay` of 100 milliseconds passes transport parameter validation. At a 5 ms RTT, the lower bound of the clamp becomes 100 ms while the upper bound is 25 ms, violating the precondition of `clamp` and panicking while driving the connection. Both automatically derived and explicitly configured maximum ACK delays use this calculation. Sending ACK_FREQUENCY frames is disabled by default, so only endpoints that opt in are affected. The flaw was corrected in 0.11.18 by computing the delay with explicit minimum and maximum bounds instead of `clamp`. Thanks to @zerox80 for reporting this issue.
Recommended action: Upgrade to 0.11.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.11.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.11.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.11.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.11.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating. A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large `retire_prior_to` value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound. The flaw was corrected in…
Recommended action: Upgrade to 0.11.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Assembler component that assembles unordered stream fragments into consecutive chunks of the stream incurs some overhead for non-contiguous fragments. Readers that read from a RecvStream in order (through an AsyncRead impl for example) will be sensitive to peers that send fragments while leaving out early parts of the stream, and in particular, fragments with many gaps (because these cannot be defragmented). In such a scenario, the receiving connection suffers from high buffer overhead, enabling memory exhaustion.
Recommended action: Upgrade to 0.11.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quictransportparameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication. Details The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics. Observed output: PoC Reproduces against the upstream Quinn server example. 1. Start server: 2. Prepare PoC client environment: 3. Run PoC script attack.py against server QUIC listener (default example target shown): Observed output…
Recommended action: Upgrade to 0.11.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations: - Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received - This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack. - Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. - This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical. Details Location of panic:…
Recommended action: Upgrade to 0.11.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Receiving unknown QUIC frames in a QUIC packet could result in a panic. Patches The problem has been fixed in 0.9.5 and 0.10.5 maintenance releases. References Fixed in https://github.com/quinn-rs/quinn/pull/1667, backported in https://github.com/quinn-rs/quinn/pull/1668 and https://github.com/quinn-rs/quinn/pull/1669.
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.