OpenSSL up to 3.4.7/3.5.8/3.6.4/4.0.2 QUIC allocation of resources

Summaryinfo

A vulnerability, which was classified as problematic, has been found in OpenSSL up to 3.4.7/3.5.8/3.6.4/4.0.2. Affected by this vulnerability is an unknown functionality of the component QUIC. This manipulation causes allocation of resources. This vulnerability appears as CVE-2026-54873. The attack may be initiated remotely. There is no available exploit. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in OpenSSL up to 3.4.7/3.5.8/3.6.4/4.0.2. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the component QUIC. The manipulation with an unknown input leads to a allocation of resources vulnerability. The CWE definition for the vulnerability is CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. As an impact it is known to affect availability. The summary by CVE is:

Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

The advisory is shared at openssl-library.org. This vulnerability is known as CVE-2026-54873 since 06/16/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/29/2026). MITRE ATT&CK project uses the attack technique T1499 for this issue.

Upgrading to version 3.4.8, 3.5.9, 3.6.5 or 4.0.3 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Network Encryption Software

Name

• OpenSSL

Version

• 3.4.0
• 3.4.1
• 3.4.2
• 3.4.3
• 3.4.4
• 3.4.5
• 3.4.6
• 3.4.7
• 3.5.0
• 3.5.1
• 3.5.2
• 3.5.3
• 3.5.4
• 3.5.5
• 3.5.6
• 3.5.7
• 3.5.8
• 3.6.0
• 3.6.1
• 3.6.2
• 3.6.3
• 3.6.4
• 4.0.0
• 4.0.1
• 4.0.2

License

• open-source

Website

• Product: https://www.openssl.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion