GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL: QUIC listener queues unlimited pending connections, exhausting server memory

CVE-2026-14456Kernel, userspace & hypervisorcurated

Impact

A remote peer that sends valid QUIC Initial packets with unknown destination connection IDs faster than the application calls SSL_accept() makes the listener allocate per-channel state without bound, until the process runs out of memory. Any service on the fleet that terminates QUIC/HTTP3 with OpenSSL 3.5 or later is exposed - internal gateways and object-store frontends included. The blast radius is the process, not the node, but a control-plane or storage frontend going down takes scheduling or data access with it. No confidentiality or integrity impact.

Who can reach it

Anyone who can reach the QUIC listener's UDP port. No authentication required - the packets are pre-handshake.

What to do

Patch OpenSSL per the 2026-08-13 advisory and restart every daemon linked against it; the fix caps pending connections at 256, and applications can retune with SSL_set_value_uint(). Only OpenSSL 3.5 and later are affected, since that is when the QUIC server was added - older branches need nothing. The FIPS module is outside the affected boundary. Finding the linked daemons is usually the expensive part; a full node reboot is a blunt but reliable substitute.

References

Related entries

All Kernel, userspace & hypervisor entries

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.