Most recent entries from all

EUVD-2026-160983

fkie_cve-2024-45311

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. 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: 1. 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. 2. 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.

GHSA-vr26-jcq5-fjj8 — Denial of service in quinn-proto when using `Endpoint::retry()`

Affected: crates.io: quinn-proto

### Summary

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: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

### Impact Denial of service for internet-facing server

RUSTSEC-2024-0373 — `Endpoint::retry()` calls can lead to panicking

Affected: crates.io: quinn-proto

In 0.11.0, we overhauled the server-side `Endpoint` implementation to enable more careful handling of incoming connection attempts. However, some of the code paths that cleaned up state after connection attempts were processed confused the initial destination connection ID with the destination connection ID of a substantial package. This resulted in the internal `Endpoint` state becoming inconsistent, which could then lead to a panic.

https://github.com/quinn-rs/quinn/commit/e01609ccd8738bd438d86fa7185a0f85598cb58f

Thanks to [@finbear](https://github.com/finnbear) for reporting and investingating, and to [@BiagoFesta](https://github.com/BiagoFesta) for coordinating.