AIKIDO-2026-404995

TL;DR

After the QUIC handshake, StreamsState::received_max_stream_data accepts a MAX_STREAM_DATA frame for a peer initiated bidirectional stream without checking the stream index against the advertised concurrency limit, and the stream opening logic then raises next_remote to that index, opening every stream up to it. A single 13 byte frame can open over a trillion streams, so a server or client built on the quinn crate's accept loop runs out of memory and aborts, stops accepting connections, or occupies several CPU cores indefinitely, instead of closing the connection with a stream limit error as RFC 9000 requires. Both QUIC servers and clients that accept bidirectional streams are affected. The fix checks the stream ID against the configured limit before opening streams and returns a stream limit error when it is exceeded.