CVE-2026-14456 in OpenSSL
Summary
by MITRE • 08/13/2026
Issue summary: When an OpenSSL QUIC server (Listener SSL object) processes valid QUIC Initial packets for unknown destination connection IDs, it can allocate and queue new incoming channels without enforcing any limit.
Impact summary: A remote peer that can make many Initial packets reach the server listener faster than the application accepts connections, can cause the memory allocated to store the per-channel state to grow without any limits, potentially making the QUIC listener unavailable and causing Denial of Service.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The function that handles inbound QUIC packets uses Connection-Id from the packet header to find an existing connection (QUIC channel). If no existing connection is found and the packet type is INITIAL, the function treats the packet as a new connection. It allocates a new channel object and inserts it into a queue where it waits to be accepted by the local application with SSL_accept(3ossl). The memory occupied by these initial channel objects may grow without bounds if the application is not able to call SSL_accept() frequently enough to serve these inbound connection requests.
The issue is present since OpenSSL 3.5 when the QUIC server implementation was added.
The fix introduces a limit for pending connections. The default limit is set to 256 pending connections (waiting to be accepted by the local application). Applications may change the default by calling SSL_set_value_uint(3ossl).
FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability described represents a critical resource exhaustion flaw in OpenSSL's QUIC server implementation that directly maps to CWE-770 Allocation of Resources Without Limits or Throttling. This weakness occurs when an OpenSSL QUIC listener processes valid Initial packets for connection IDs that do not correspond to existing connections, leading to unbounded memory allocation through the creation of new channel objects without proper rate limiting mechanisms. The flaw specifically affects versions 3.5 and later where the QUIC server functionality was introduced, making it a design-time issue rather than a simple patchable bug.
The technical implementation flaw stems from the packet handling logic that indiscriminately allocates new channel objects when processing incoming Initial packets with unknown destination connection IDs. When no existing connection is found, the system treats each such packet as a new connection attempt and creates a corresponding channel object stored in a queue awaiting application acceptance via SSL_accept() calls. This mechanism lacks any enforcement of maximum pending connection limits, allowing an attacker to flood the server with valid Initial packets that generate new channel objects faster than the application can process them through SSL_accept() calls.
The operational impact of this vulnerability manifests as a potential denial of service condition where the QUIC listener becomes unavailable due to uncontrolled memory growth. The attacker can exploit this by sending multiple Initial packets at sufficient frequency to ensure that the queue of pending connections grows indefinitely, eventually exhausting system resources and preventing legitimate connection establishment. This behavior represents a classic resource exhaustion attack pattern that aligns with ATT&CK technique T1499.004 for Resource Exhaustion and potentially T1595.001 for Network Denial of Service.
The fix implemented addresses the root cause by introducing a configurable limit for pending connections with a default threshold of 256 waiting connections, effectively throttling the resource consumption while maintaining application flexibility through the SSL_set_value_uint() API call. This mitigation strategy directly addresses the CWE-770 weakness by establishing clear boundaries on resource allocation and provides a balance between security and operational requirements. The solution aligns with industry best practices for preventing resource exhaustion attacks and follows the principle of least privilege in resource management.
The FIPS module is unaffected by this vulnerability as the QUIC implementation exists outside the FIPS boundary, which means that systems using FIPS-certified modules remain protected from this specific resource exhaustion attack vector. However, administrators should ensure that all OpenSSL components are updated to versions containing this fix, regardless of FIPS status, to maintain overall system security posture and prevent potential exploitation through other attack vectors that may leverage similar resource management weaknesses in the broader OpenSSL ecosystem.