Summary
s2n-quic has excessive memory allocation
Advisory details
s2n-quic is a Rust implementation of the QUIC protocol. An unauthenticated user can attempt to exhaust server memory on an s2n-quic endpoint by sending crafted CRYPTO frames with high offsets. The buffer used for processing CRYPTO frames does not enforce a maximum size. In the worst case, a single 1200-byte packet can cause approximately 9.4 MB of allocation. By repeatedly sending such packets, the resulting memory pressure could cause denial of service. No valid handshake is required.
Impacted versions: <= v1.81.0
Patches
This issue has been addressed in s2n-quic version v1.82.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
There is no workaround that fully mitigates this issue. Upgrading to the patched version is the recommended remediation.
References
If there are any questions or comments about this advisory, contact AWS Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
References
Related vulnerabilities
All Supply chain →- MEDIUMCVE-2026-71486
vLLM: Derender endpoints decode caller-supplied GenerateResponse token IDs without output bounds
- HIGHCVE-2026-79921
amqp091-go has a Potential Memory Exhaustion/Protocol Violation via Broker-Controlled Oversized Payload
- HIGHCVE-2026-67446
Mailpit: Thumbnail generation decodes unbounded image dimensions before scaling
- MEDIUMCVE-2026-82562
qs array-limit bypass via bracket-key comma parsing
- MEDIUMGHSA-8423-8fgw-73vq
tornado: multipart split() creates huge temp list before max_parts check -> memory amplification DoS (httputil.py:34)
- MEDIUMCVE-2026-73228
Django REST framework: Potential bypass of Django `DATA_UPLOAD_MAX_MEMORY_SIZE` when parsing oversized JSON and urlencoded request bodies via DRF `request.data`