OpenSSL QUIC server: per-packet credit accounting breaks the RFC 9000 3x amplification limit

UnscoredCVE-2026-35191Kernel, userspace & hypervisorcurated

Impact

When a QUIC server built on OpenSSL runs with client address validation disabled, it adds the length of the entire received datagram to its unvalidated send credit once per QUIC packet in that datagram. A peer that packs multiple packets into one datagram makes the server believe far more data arrived than did, so the server will emit more than the 3x reply volume the RFC allows before the handshake completes. The consequence is not a compromise of the server: it is that the server becomes a usable amplifier in a spoofed-source DDoS against a third party. For an operator this is an egress and reputation problem on any public QUIC listener in front of the fleet, and it only applies to deployments that turned address validation off.

Who can reach it

A remote attacker able to spoof source addresses toward a QUIC listener that has address validation disabled. No authentication needed; the abuse happens before the handshake completes.

What to do

Update OpenSSL and restart the QUIC-serving daemons. As an immediate mitigation that needs no patch, re-enable client address validation (retry tokens) on the QUIC server, which restores the intended check. No fixed version is stated in this record beyond the advisory and commits.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-35191 https://openssl-library.org/news/secadv/20260929.txt https://github.com/openssl/openssl/commit/0fe4442d4f8ea3af8a174046dae176e0d4717239

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.