CVE-2026-115482 in lsquic
Summary
by MITRE • 10/23/2026
In lsquic before 4.9.0, the HTTP/3 implementation can use an excessive amount of memory because the number of buffered header sets is not limited, as demonstrated by a QPACK amplification attack. This is related to header_out_dynamic_entry and es_max_header_list_size.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in lsquic versions prior to 4.9.0 represents a critical resource exhaustion flaw within the HTTP/3 implementation, specifically affecting the QUIC protocol stack's handling of QPACK encoded headers. This issue stems from an absence of strict enforcement on the quantity of buffered header sets maintained by the library during connection establishment and data transmission phases. In normal operation, HTTP/3 relies heavily on QPACK to compress and decompress HTTP header fields efficiently over a compressed stream. However, when the implementation fails to cap the number of dynamic entries or buffer slots allocated for these headers, it becomes susceptible to unbounded memory allocation triggered by maliciously crafted network traffic.
The technical root cause lies in the interaction between the header_out_dynamic_entry mechanism and the es_max_header_list_size configuration parameter. While the latter is intended to set a limit on the size of the header list, the former allows for dynamic entry insertion without sufficient validation against global memory constraints or connection-level quotas. An attacker can exploit this by sending a high volume of requests with unique or rapidly changing headers, forcing the server to allocate new entries in its internal tables repeatedly. Because there is no hard limit on the number of buffered header sets, the application continues to consume RAM for each incoming request's metadata until system resources are depleted. This behavior effectively transforms standard HTTP/3 traffic into a vector for denial-of-service attacks through resource amplification.
From an operational perspective, this vulnerability enables what is known as a QPACK amplification attack. By saturating the server with requests that trigger excessive header buffering, an adversary can cause the lsquic process to consume all available memory on the host machine. This leads to severe performance degradation for legitimate users and ultimately results in service unavailability as the operating system may begin killing processes or swapping heavily, rendering the application non-functional. The impact is particularly acute because HTTP/3 connections are often long-lived and handle significant volumes of metadata compared to traditional TCP-based HTTP implementations where header compression mechanisms differ significantly.
This flaw aligns with CWE-789: Memory Allocation with Excessive Size, as well as CWE-400: Uncontrolled Resource Consumption. In the context of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Denial of Service via resource exhaustion, specifically targeting application layer resources rather than network bandwidth alone. The attack vector is remote and requires no authentication, making it a high-severity threat for any public-facing service utilizing lsquic as its QUIC implementation.
To mitigate this risk, organizations must upgrade to lsquic version 4.9.0 or later where the developers have implemented stricter limits on buffered header sets. Administrators should also review their deployment configurations to ensure that es_max_header_list_size is set appropriately for their workload characteristics and not left at default values that may be too permissive under attack conditions. Additionally, implementing rate limiting at the network edge can help dampen the volume of requests reaching the application layer during potential abuse scenarios. Monitoring memory usage trends in conjunction with HTTP/3 connection counts can provide early warning indicators of such exploitation attempts before critical resource thresholds are breached.