Quinn affected by unauthenticated remote DoS via panic in QUIC transport parameter parsing

Summary

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 quic_transport_parameters. 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:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program