Imperva Offensive team discovered that threat actors could smuggle malformed packets to exhaust memory and crash QUIC servers even before a connection handshake is established, therefore, bypassing QUIC connection-level safeguards.
Executive Summary
QUIC-LEAK (CVE-2025-54939) is a newly discovered pre-handshake memory exhaustion vulnerability in the LSQUIC QUIC implementation, the second most widely used implementation after Quiche. Identified by the Imperva Offensive Team, this flaw allows remote attackers to crash vulnerable executables by memory exhaustion and enforce a denial-of-service (DoS).
Because the vulnerability is triggered before any handshake occurs, it bypasses all standard QUIC protections—including connection limits, stream controls, and flow regulation—which only apply after a session is established. As a result, QUIC’s core defenses are rendered ineffective, and the server is left exposed to rapid and unbounded memory growth and eventual process termination due to out-of-memory (OOM) conditions.
If you are using any technology that relies on the LiteSpeed QUIC library, it is strongly recommended to upgrade to version 4.3.1 or later. This fix is included in OpenLiteSpeed 1.8.4 and LiteSpeed Web Server 6.3.4.
We thank LiteSpeed Technologies for their prompt response and for delivering a fix that helps protect production systems globally.
Introduction
QUIC is a modern transport protocol developed by Google, designed to replace TCP in many latency-sensitive contexts. Built on top of UDP, it offers features such as 0-RTT handshakes, multiplexed streams without Head-of-Line Blocking (HOLB), and integrated TLS 1.3 encryption.
QUIC forms the transport foundation of HTTP/3, and is quickly being adopted by major players. Several open-source implementations have emerged, such as Quiche (Cloudflare), mvfst (Meta), and LSQUIC, developed by LiteSpeed Technologies.
LSQUIC is deployed widely in production environments. It powers QUIC and HTTP/3 support in all LiteSpeed Web Server and OpenLiteSpeed installations, technologies used by many hosting providers and cloud platforms. As of 2025, LiteSpeed serves over 14% of all websites and more than 34% of HTTP/3-enabled sites, making it the second most common HTTP/3 server on the web after Cloudflare Quiche. On AWS, LiteSpeed is listed among the top three most popular web servers in the Marketplace, with prebuilt stacks for Node.js, WordPress, and others. As a result, countless companies are running LSQUIC in production, sometimes unknowingly, simply by deploying LiteSpeed-powered infrastructure.
But even mature stacks can harbor flaws, especially in areas as complex as QUIC packet parsing. While auditing LSQUIC, we discovered a vulnerability affecting how the stack handles packets coalesced into a single datagram.
Structure of QUIC Initial Packets
QUIC Initial packets are used to initiate a connection. They have a long header format and must comply with specific size and structure constraints, including:
Fig. 1: QUIC Initial packet usual structure
The Destination Connection ID (DCID) identifies the connection from the server’s perspective. In the Initial packet, the client may use a random DCID. Upon receiving this, the server responds with its own Source Connection ID (SCID), which the client then adopts as the DCID in all subsequent packets.
The Token field is part of an address validation mechanism that ensures the client genuinely controls the IP address it claims.
Several properties of Initial packets include:
- Minimum size requirement of 1200 bytes (as per [RFC 9000, §14]).
- They typically carry a CRYPTO frame to initiate the TLS 1.3 handshake.
- Packet coalescing is allowed, meaning multiple Initial packets can be combined into a single UDP datagram for transmission.
As specified in the IETF QUIC transport RFC v34, section 7.2 : “Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection.”
However, an oversight in LSQUIC’s DCID validation leads to silent memory leaks, as we’re going to see.
Smuggling Coalesced Packets
Let’s visualize a malicious datagram crafted by an attacker:
Fig. 2: Malicious UDP Datagram
A single UDP datagram can hold up to ~65,535 bytes but on a typical 1500-byte MTU path the UDP payload is usually 1472 bytes. Each QUIC Initial packet is at least 1200 bytes long leaving roughly 272 bytes available — enough to coalesce 10 minimal Handshake packets (with 8-byte DCIDs and SCIDs).
In this attack, only the first packet has a valid DCID. The remaining packets violate the RFC but are still allocated in memory by LSQUIC. Instead of freeing those invalid packets, LSQUIC keeps them allocated—creating a persistent memory leak.
This happens silently and before any connection is established.
The Vulnerable Code
In one of the code paths of the lsquic_engine.c we identified the following section of code:
Fig. 3: Vulnerable Snippet of code
For each parsed packet in the datagram, the code first checks if it’s an IETF QUIC packet and whether the Destination Connection ID matches the expected one. If not, the packet is ignored and its size is added to the garbage count to help the server enforce response limits.
As specified in the IETF QUIC transport RFC v34, section 8 :
” […] an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address.”
This mechanism protects against amplification attacks by ensuring the server does not respond disproportionately to potentially spoofed or malformed packets.
However, unlike in the case of valid packets, the packet_in structure is not explicitly freed using lsquic_mm_put_packet_in. To further our investigation, we decided to instrument an LSQUIC server using the following gdb script, which enabled us to follow allocation and deallocation of packet_in instances during the engine’s execution and while simulating an attack with a series of UDP datagrams with 50 smuggled Initial packets.
Fig. 4: GDB script to investigate the issue
This ended up with the following kinds of logs:
Fig. 5: GDB Script output
Simultaneously, the memory of the process was monitored, and it showed a sharp increase of RAM memory.
This helped us identify precisely the loss of memory during the server’s execution and confirm our first analysis: only the first packet was freed.
Once we reached this point, we contacted LiteSpeed Technologies with our findings.
Impact
Because the attack works without completing a handshake, it’s completely stateless from the attacker’s perspective:
- No need for a valid QUIC session which is costly for a threat actor.
- No dependency on response or any other timing dependency
By sending many such datagrams, an attacker causes linear memory growth, which may trigger the Out-of-Memory killer (OOM) on vulnerable servers. In this case, the target is the http_server reference implementation embedded in the lsquic library. This results in denial of service, as illustrated by the following log entry:
[30853.818134] Memory cgroup out of memory: Killed process 60062 (http_server)
How bad can it get?
For each packet, the packet_in structure consumes 0x60 (~96) bytes, which results—at worst—in approximately 960 bytes of RAM per UDP datagram (1472 byte payload). Since the attack can be repeated indefinitely, memory consumption grows rapidly and ultimately crashes the server through exhaustion. In this context, the memory grows at 70% of the bandwidth rate, making the attack still highly effective over time.
A successful denial-of-service attack can render a service unavailable, disrupt operations, and in some contexts (e.g., financial, industrial, or medical systems), lead to serious downtime, data loss, or safety risks.
Note: While MITRE currently assigns a CVSS 3.1 base score of 5.3, our analysis—based on new evidence presented in this blog post—rates the availability impact as High (A:H), resulting in a revised base score of 7.5.
LiteSpeed Servers
Since LiteSpeed servers depend on lsquic library, they inherit this vulnerability by integration. The issue has been fixed in OpenLiteSpeed 1.8.4 and LiteSpeed Web Server 6.3.4.
Until fixes are available, users should limit UDP traffic, monitor for anomalies, and upgrade to a fix version where possible.
We conducted an experiment using Locust to evaluate the memory impact of the attack under realistic conditions. The goal was to send the same amount of traffic in two phases—first using valid Initial packets followed by valid packets (with correct DCID) to establish a baseline. In the second phase, we sent Initial packets followed by smuggled packets with invalid DCIDs, triggering the vulnerability The following setup was used:
- Server: OpenLiteSpeed with WordPress
- Memory: 512 MiB (minimum required)
- Workers: 4 (default)
- Swap: Disabled (default on AWS)
- Locust load: 10 users, 1 request every 2 seconds, 20s timeout
As soon as the memory reaches 100%, the server became unresponsive (See Fig. 6)
Fig. 6: Impact of QUIC-LEAK on a Lite Speed web server
Timeline
July 15, 2025 – The vulnerability was responsibly disclosed to LightSpeed Technologies.
July 18, 2025 – LightSpeed Technologies released a patch addressing the issue in LSQUIC, however, many upstream projects that depend on LSQUIC remain vulnerable.
July 30, 2025 – We contacted MITRE to request a CVE reservation.
August 1, 2025 – MITRE publicly published the CVE entry.
August 1, 2025 – LightSpeed Technologies released new versions of OpenLiteSpeed and LiteSpeed Web Server including the patch.
August 18, 2025 – Following the public disclosure, we issued a public advisory detailing the vulnerability.
Mitigation
To prevent exploitation of this vulnerability, users of technologies based on the LiteSpeed QUIC library are strongly advised to upgrade to version 4.3.1, which includes a fix for the memory leak issue. This upgrade is included in OpenLiteSpeed 1.8.4 and LiteSpeed Web Server 6.3.4.
Given the potential for widespread impact, we ensured that other key security vendors — including Akamai and Cloudflare — were informed to help protect their customers.
Organizations unable to upgrade immediately should consider applying network-level protections, enforcing memory usage limits on exposed services, and closely monitoring for unusual UDP traffic patterns.
Conclusion
QUIC is still a young, evolving protocol, and LSQUIC evolves alongside it. QUIC-LEAK reminds us that even widely deployed libraries can harbor issues, so keep LSQUIC up to date and stay tuned to security advisories to ensure your HTTP/3 deployments remain resilient.
The post QUIC-LEAK (CVE-2025-54939): New High-Risk Pre-Handshake Remote Denial of Service in LSQUIC QUIC Implementation appeared first on Blog.
