RUSTSEC-2026-0523: MAX_STREAM_DATA frame can open streams beyond the stream limit
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 48/100
Research direction
The payload names only the vulnerable crate, quinn-proto 0.11.17, and the patched range >=0.11.19; it does not show where the gateway uses it. Start with cargo tree -i quinn-proto to see whether it is a direct or transitive dependency, then check Cargo.toml and Cargo.lock. Done when the lockfile resolves to a patched version, cargo build and the test suite pass, and cargo audit no longer reports RUSTSEC-2026-0523.
Written by the indexing model from the issue text.
Description
MAX_STREAM_DATA frame can open streams beyond the stream limit
| Details | |
|---|---|
| Package | quinn-proto |
| Version | 0.11.17 |
| URL | https://github.com/quinn-rs/quinn/commit/3eb7465d9e11d7a245e99cde1a4eb872ec26d264 |
| Date | 2026-09-30 |
| Patched versions | >=0.11.19 |
| Unaffected versions | <0.11.0 |
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.
See advisory page for additional details.
- Dominant language
- Rust
- Stars
- 0
- Forks
- 2
- Avg merge
- 14d 2h
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stackabletech/postgresql-trino-gateway
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationOpen
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 Under an hour Newbie friendliness 50/100
All issues in stackabletech/postgresql-trino-gateway
Similar issues
-
bug UI
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
wardian-app/Wardian#1746 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
jlcodes99/cockpit-tools#3125 ·
Maintainers usually reply within 2 days
-
bug user-sprint
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Vondor/KassenSturz#967 ·
Maintainers usually reply within 1 day