OpenSSL QUIC: quadratic stream reassembly lets a peer burn CPU with in-window frames

UnscoredCVE-2026-42772Kernel, userspace & hypervisorcurated

Impact

OpenSSL keeps received QUIC stream fragments on a doubly-linked list optimised for appends; any fragment that does not follow the current tail triggers a head-to-tail linear scan. A peer that chooses its frame offsets deliberately forces O(n^2) work per stream while staying inside the advertised receive window and sending fully compliant frames, so the cost falls on the server's CPU at very low attacker bandwidth. That is connection-scoped CPU exhaustion against whatever process terminates QUIC - a gateway or proxy in front of inference endpoints - and it is indistinguishable from legitimate out-of-order traffic at the packet level, so rate limits keyed on volume will not catch it.

Who can reach it

Any remote peer that can complete the QUIC handshake, so authentication at the application layer is irrelevant - reaching the QUIC listener is enough.

What to do

Update OpenSSL and restart the QUIC-terminating daemons. No fixed version is given in this record beyond the advisory and the linked commits. If patching must wait, the exposure is limited to processes that actually serve QUIC, so disabling QUIC/HTTP3 on public listeners removes the attack surface at the cost of falling back to TCP.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-42772 https://openssl-library.org/news/secadv/20260929.txt https://github.com/openssl/openssl/commit/32d0ed8afe1b8c3e7ece725b44663da3d7087a09

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.