Skip to main content
Menu
CVEs

CVE

quinn-proto denial of service via crafted MAX_STREAM_DATA frame

RUSTSEC-2026-0523GHSA-53RM-773F-4Q8C

Exploited
No known exploitation
Fix
Fixed in 0.11.19
Who is exposed
Not reported

Do first: Upgrade to a fixed version: 0.11.19.

Published
Last modified
Reference
Last checked
20/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

The quinn-proto package accepts a MAX_STREAM_DATA frame that names a peer-initiated bidirectional stream not yet open, so a connected peer can send one small frame with a very large stream index and make every lower-numbered stream appear open. This can exhaust memory, stop new connections from being accepted, or keep the endpoint busy indefinitely, and it affects clients and servers that accept peer-initiated bidirectional streams, though not unidirectional ones.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

Read the original 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.

cve.now Index

20Pcve.now Index 20 of 100 · methodology v3 · provisional
  • Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
  • Exposure?/25Unknown. No advisory context yet
  • Reach20/20quinn-proto: 11.8M downloads a week
  • Severity?/10Unknown. No CVSS score or vendor rating
  • No patch0/5No signal

What would change the score

  • Would score about 75 if added to CISA KEV
  • Would score about 70 if CISA's SSVC rates exploitation active
  • Would score about 42 if advisories confirm default setups are exposed

Impact

  • Widely used

    quinn-proto has 11.8m weekly downloads.Source: crates.io

What to do

  • Upgrade to a fixed version: 0.11.19.

Check your systems with an agent

Paste this into a coding or ops agent. It checks your systems read-only and reports a table per asset.

Check whether my systems are affected by RUSTSEC-2026-0523 (MAX_STREAM_DATA frame can open streams beyond the stream limit), using the cve.now data below.

Rules: work read-only. Do not run exploit code, proof-of-concept scripts or scanners that send attack payloads, and do not change any configuration, package, image or deployment. Report findings only.

What cve.now has for RUSTSEC-2026-0523 (entry last updated 2026-11-13):
Affected:
- crates.io package quinn-proto: from 0.11.0, fixed in 0.11.19
Fixed versions: 0.11.19.
Setup: unknown whether the bug needs a non-default feature or setting. Check the advisory.
CISA KEV: RUSTSEC-2026-0523 is not listed as of cve.now's last read.
This KEV status is for RUSTSEC-2026-0523 only. If you also check another CVE, look up its own KEV status; never assume it from this one.

How to check:
- Packages (crates.io): find every lockfile in each project and run the stack.check operation of the cve.now MCP server (execute) on each one. Compare the resolved versions, not the ranges a manifest declares, with the affected versions above. Include transitive dependencies.

Verify against the linked advisories before concluding, and cite the date you read each one:
- https://rustsec.org/advisories/RUSTSEC-2026-0523.html
- https://crates.io/crates/quinn-proto
- https://github.com/quinn-rs/quinn/commit/3eb7465d9e11d7a245e99cde1a4eb872ec26d264
- https://github.com/quinn-rs/quinn/commit/73114d8289d42bd536c790fa00a9beed05a4e5fa
Do not conclude an asset is unaffected unless you checked it and the evidence covers both its version and the conditions above. If you could not check something, mark it unknown and say what is missing.

Report a table with one row per asset and these columns: Asset | Version or build | Status (affected, fixed, not applicable, unknown) | Compensating controls | Exposure (internet-facing, internal, none) | Evidence | Next action.

Entry: https://cve.now/RUSTSEC-2026-0523
For follow-up questions, use the cve.now MCP server at https://mcp.cve.now/mcp (no authentication), for example execute with name cve.get and arguments {"id": "RUSTSEC-2026-0523"}.

Timeline

  1. Advisory published44 days
  2. Record last updated

Affected versions

  • quinn-protocrates.io

    From 0.11.0 · fixed in 0.11.19

    Fixed in 0.11.19 (released Sep 30, 2026, the day of disclosure).

    The latest release, 0.11.19, is not affected.

Evidence 4

Other links · 4

  1. Advisory
  2. Repository
  3. Repository
  4. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

Questions about RUSTSEC-2026-0523

Is RUSTSEC-2026-0523 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by RUSTSEC-2026-0523?

quinn-proto (crates.io): from 0.11.0 before 0.11.19.Source: cve.now feed data

How do I fix RUSTSEC-2026-0523?

Upgrade to a fixed version: 0.11.19.Source: cve.now feed data