Long Retry token can panic or exhaust memory in a QUIC client

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

not scored

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

A client kept the token from a Retry packet without any length limit and put it into the header of every Initial packet it sent afterwards. Initial datagrams are 1200 bytes. When the token and connection IDs left no room for the minimum payload, `PacketBuilder::new` computed a minimum packet size larger than the maximum, which only a debug assertion checked. On the next `poll_transmit`, debug builds panic, and release builds try to allocate more than 10 GiB in one call. With longer tokens the allocation fails and the process aborts. A matching Retry packet can be built from the client's first Initial alone. The attacker can therefore be the server being contacted, or anyone who sees that Initial and can answer before the server does. Every application that makes outgoing connections with `quinn-proto` is affected, including all `quinn` clients. Servers do not process Retry packets. The fix closes the connection with `PROTOCOL_VIOLATION` when an Initial token leaves too little room…

Published by the source

30 Sep 2026, 12:00 UTC

Last modified by the source

13 Nov 2026, 12:45 UTC

Source last checked

14 Nov 2026, 08:25 UTC

1. Revision 1 · created · 14 Nov 2026

   Published from osv record RUSTSEC-2026-0524

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-wppq-2f6r-wfvm

Advisory: Long Retry token can panic or exhaust memory in a QUIC client
IDs: GHSA-wppq-2f6r-wfvm
Record: https://patchnext.com/advisories/rustsec-2026-0524 (revision 1, source checked 14 Nov 2026, 08:25 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Unrated
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: quinn-proto 0.11.19. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io quinn-proto: affected >= 0.11.0, < 0.11.19; fixed in 0.11.19

## Suggested inspection (read-only)
- crates.io quinn-proto: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on quinn-proto.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/RUSTSEC-2026-0524 (OSV record RUSTSEC-2026-0524 lists affected ranges: crates.io quinn-proto >=0.11.0 <0.11.19 (fixed))

Commands are suggestions: review each one before running it.