GHSA-53rm-773f-4q8c
MAX_STREAM_DATA frame can open streams beyond the stream limit
GHSA-53rm-773f-4q8c is a vulnerability with no CVSS score yet in quinn-proto, published September 30, 2026. No source lists public exploit code. Fixed in quinn-proto 0.11.19.
- Severity
- UnratedNo CVSS score yet
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
0.11.19quinn-proto
Description
When a MAX_STREAM_DATA frame named a peer-initiated bidirectional stream that was not open yet, received_max_stream_data treated the stream, and every lower-numbered stream, as opened without checking the stream ID against the limit advertised to the peer. RFC 9000 section 4.6 requires closing the connection with STREAM_LIMIT_ERROR in this case, and the STREAM and RESET_STREAM handlers already did so.
After the handshake, a peer can send one small MAX_STREAM_DATA frame naming a very large stream index, and accept then yields every stream up to that index. In quinn, a loop that keeps calling accept_bi can be handed more than 2^40 streams. Depending on the runtime, the endpoint runs out of memory, stops accepting new connections, or keeps busy indefinitely, even after the peer has gone away. Clients and servers that accept peer-initiated bidirectional streams are affected. Unidirectional streams are not.
The fix validates the stream ID in received_max_stream_data and adds a defensive check where streams are opened implicitly. It is in 0.11.19.
Affected packages
| Package | Affected | Fixed |
|---|---|---|
quinn-protocrates.io | 0.11.0 up to 0.11.19 | 0.11.19 |
What each source reports
OSVRUSTSEC-2026-0523No score
MAX_STREAM_DATA frame can open streams beyond the stream limit
When a MAX_STREAM_DATA frame named a peer-initiated bidirectional stream that was not open yet, received_max_stream_data treated the stream, and every lower-numbered stream, as opened without checking the stream ID against the limit advertised to the peer. RFC 9000 section 4.6 requires closing the connection with STREAM_LIMIT_ERROR in this case, and the STREAM and RESET_STREAM handlers already did so.
After the handshake, a peer can send one small MAX_STREAM_DATA frame naming a very large stream index, and accept then yields every stream up to that index. In quinn, a loop that keeps calling accept_bi can be handed more than 2^40 streams. Depending on the runtime, the endpoint runs out of memory, stops accepting new connections, or keeps busy indefinitely, even after the peer has gone away. Clients and servers that accept peer-initiated bidirectional streams are affected. Unidirectional streams are not.
The fix validates the stream ID in received_max_stream_data and adds a defensive check where streams are opened implicitly. It is in 0.11.19.
- Record
RUSTSEC-2026-0523- Updated
- 2026-11-13
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.