{“lastseen”:”2025-08-18T18:04:09″,”description”:”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.\\n\\n## **Executive Summary**\\n\\nQUIC-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).\\n\\nBecause the vulnerability is triggered _before_ any handshake occurs, it bypasses all standard QUIC protections\u2014including connection limits, stream controls, and flow regulation\u2014which only apply _after_ a session is established. As a result, QUIC\u2019s 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.\\n\\nIf 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.\\n\\nWe thank LiteSpeed Technologies for their prompt response and for delivering a fix that helps protect production systems globally.\\n\\n## **Introduction**\\n\\nQUIC 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.\\n\\nQUIC 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.\\n\\nLSQUIC 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.\\n\\nBut 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.\\n\\n**Structure of QUIC Initial Packets**\\n\\nQUIC Initial packets are used to initiate a connection. They have a long header format and must comply with specific size and structure constraints, including:\\n\\n_Fig. 1: QUIC Initial packet usual structure_\\n\\nThe 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.\\n\\nThe Token field is part of an address validation mechanism that ensures the client genuinely controls the IP address it claims.\\n\\nSeveral properties of Initial packets include:\\n\\n * Minimum size requirement of 1200 bytes (as per [RFC 9000, \u00a714]).\\n * They typically carry a CRYPTO frame to initiate the TLS 1.3 handshake.\\n * Packet coalescing is allowed, meaning multiple Initial packets can be combined into a single UDP datagram for transmission.\\n\\n\\n\\nAs 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.\\”\\n\\nHowever, an oversight in LSQUIC’s DCID validation leads to silent memory leaks, as we\u2019re going to see.\\n\\n## **Smuggling Coalesced Packets**\\n\\nLet\u2019s visualize a malicious datagram crafted by an attacker:\\n\\n_Fig. 2: Malicious UDP Datagram_\\n\\nA 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 \u2014 enough to coalesce 10 minimal Handshake packets (with 8-byte DCIDs and SCIDs).\\n\\nIn 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\u2014creating a persistent memory leak.\\n\\nThis happens silently and before any connection is established.\\n\\n## **The Vulnerable Code**\\n\\nIn one of the code paths of the lsquic_engine.c we identified the following section of code:\\n\\n_Fig. 3: Vulnerable Snippet of code_\\n\\nFor 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.\\n\\n_As specified in the IETF QUIC transport RFC v34, section 8 :_\\n\\n_\\” [\u2026] 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.\\”_\\n\\nThis mechanism protects against amplification attacks by ensuring the server does not respond disproportionately to potentially spoofed or malformed packets.\\n\\nHowever, 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\u2019s execution and while simulating an attack with a series of UDP datagrams with 50 smuggled Initial packets.\\n\\n_Fig. 4: GDB script to investigate the issue_\\n\\nThis ended up with the following kinds of logs:\\n\\n_Fig. 5: GDB Script output_\\n\\nSimultaneously, the memory of the process was monitored, and it showed a sharp increase of RAM memory.\\n\\nThis helped us identify precisely the loss of memory during the server\u2019s execution and confirm our first analysis: only the first packet was freed.\\n\\nOnce we reached this point, we contacted LiteSpeed Technologies with our findings.\\n\\n## **Impact**\\n\\nBecause the attack works without completing a handshake, it\u2019s completely stateless from the attacker\u2019s perspective:\\n\\n * No need for a valid QUIC session which is costly for a threat actor.\\n * No dependency on response or any other timing dependency\\n\\n\\n\\nBy 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:\\n\\n_[30853.818134] Memory cgroup out of memory: Killed process 60062 (http_server)_\\n\\n## **How bad can it get?**\\n\\nFor each packet, the packet_in structure consumes 0x60 (~96) bytes, which results\u2014at worst\u2014in 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.\\n\\nA 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.\\n\\n_Note: While MITRE currently assigns a CVSS 3.1 base score of 5.3, our analysis\u2014based on new evidence presented in this blog post\u2014rates the availability impact as High (A:H), resulting in a revised base score of 7.5._\\n\\n## **LiteSpeed Servers**\\n\\nSince 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.\\n\\nUntil fixes are available, users should limit UDP traffic, monitor for anomalies, and upgrade to a fix version where possible.\\n\\nWe 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\u2014first 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:\\n\\n * Server: OpenLiteSpeed with WordPress\\n * Memory: 512 MiB (minimum required)\\n * Workers: 4 (default)\\n * Swap: Disabled (default on AWS)\\n * Locust load: 10 users, 1 request every 2 seconds, 20s timeout\\n\\n\\n\\nAs soon as the memory reaches 100%, the server became unresponsive (See Fig. 6)\\n\\n_Fig. 6: Impact of QUIC-LEAK on a Lite Speed web server_\\n\\n## **Timeline**\\n\\nJuly 15, 2025 \u2013 The vulnerability was responsibly disclosed to LightSpeed Technologies.\\n\\nJuly 18, 2025 \u2013 LightSpeed Technologies released a patch addressing the issue in LSQUIC, however, many upstream projects that depend on LSQUIC remain vulnerable.\\n\\nJuly 30, 2025 \u2013 We contacted MITRE to request a CVE reservation.\\n\\nAugust 1, 2025 \u2013 MITRE publicly published the CVE entry.\\n\\nAugust 1, 2025 \u2013 LightSpeed Technologies released new versions of OpenLiteSpeed and LiteSpeed Web Server including the patch.\\n\\nAugust 18, 2025 \u2013 Following the public disclosure, we issued a public advisory detailing the vulnerability.\\n\\n## **Mitigation**\\n\\nTo 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.\\n\\nGiven the potential for widespread impact, we ensured that other key security vendors \u2014 including Akamai and Cloudflare \u2014 were informed to help protect their customers.\\n\\nOrganizations 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.\\n\\n## **Conclusion**\\n\\nQUIC 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.\\n\\nThe post QUIC-LEAK (CVE-2025-54939): New High-Risk Pre-Handshake Remote Denial of Service in LSQUIC QUIC Implementation appeared first on Blog.”,”published”:”2025-08-18T17:23:11″,”modified”:”2025-08-18T17:23:11″,”type”:”impervablog”,”title”:”QUIC-LEAK (CVE-2025-54939): New High-Risk Pre-Handshake Remote Denial of Service in LSQUIC QUIC Implementation”,”source”:””,”references”:””,”id”:”IMPERVABLOG:6F0FDC9B1E16D098F2CF20DB42B0108A”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[“CVE-2025-54939″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:5.3,”severity”:”MEDIUM”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:N\/I:N\/A:L”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.imperva.com\/blog\/quic-leak-cve-2025-54939-new-high-risk-pre-handshake-remote-denial-of-service-in-lsquic-quic-implementation\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-08-18T18:04:09″,”description”:”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,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,22,12,59,21,13,7,11,5],"class_list":["post-13321","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-cvss-53","tag-exploit","tag-impervablog","tag-medium","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n