EUVD-2026-108211
GHSA-mhr4-9xv4-xpwf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessOpen HTTP/3 QUIC connection to lsquic server
-
ExploitStream many QPACK-encoded header sets
-
ExecutionUnbounded buffering of completed header sets
-
ImpactServer memory exhausted, denial of service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the target to expose an lsquic-based HTTP/3 (IETF QUIC) endpoint that buffers completed header sets for application processing; versions before 4.9.0 applied NO limit on the number of buffered header sets, so default configurations were affected - no special feature toggle or authentication is needed. The only practical limiting factor is reachability of the HTTP/3 service (UDP/QUIC must be enabled and routable to the attacker); there is no user interaction and no authentication requirement (PR:N). The fix in 4.9.0 introduces the es_max_header_sets setting (default 1 in server mode, 2 in client mode) that suspends HTTP/3 parsing on a stream once the buffered-set limit is reached, so patched/configured deployments are not exploitable. |
| Impact | All severity signals align on a network-reachable, unauthenticated availability-only issue: the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H maps cleanly to CWE-770 (unbounded buffering of completed header sets), with no confidentiality or integrity impact - this is a pure denial-of-service via memory exhaustion (QPACK amplification). No EPSS score was supplied, and the CVE is NOT on CISA KEV, so there is no evidence of active exploitation; exploitation status is best described as a public PoC reference existing (the foxio.io write-up and the fix PR) rather than confirmed in-the-wild use. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious but non-emergency DoS. The signals are mutually consistent - there is no conflict between CVSS and description - so the main caveat is simply that EPSS is absent and exploitation remains unproven in practice. Net: a genuine, straightforward-to-trigger availability risk for any HTTP/3-enabled lsquic deployment, but one whose impact is bounded to service disruption, not compromise. |
| Exploit ScenarioDerived | An attacker opens an HTTP/3 (IETF QUIC) connection to a server built on lsquic and streams a large volume of QPACK-encoded header sets faster than the application claims them; because the number of buffered completed header sets was never capped before 4.9.0, server memory grows without bound until the process is exhausted. A public PoC reference describing this QPACK amplification technique exists (foxio.io), but it is not verified as working exploit code. The low attack complexity and lack of any authentication (AC:L/PR:N/UI:N) make the attack cheap to attempt remotely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 22, 2026
Unauthenticated memory exhaustion in LiteSpeed's lsquic HTTP/3 stack (all versions before 4.9.0) allows a remote attacker to drive a server or client into high memory use and ultimately denial of service by sending header blocks that pile up completed header sets faster than the application claims them, a technique the reporters call a QPACK amplification attack. Any lsquic-based endpoint that exposes HTTP/3 over UDP/QUIC is affected with default settings, since the library applied no cap on buffered header sets; no credentials or user interaction are needed and the vector scores 7.5 (AV:N/AC:L/PR:N/UI:N, availability-only). There is confirmed vendor activity in the form of upstream pull request 666 and the 4.9.0 release notes, and a public research write-up from FoxIO describes the attack class, but no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
RemediationAI
Vendor-released patch: lsquic 4.9.0 - upgrade to 4.9.0 (or later) from the upstream repository, see https://github.com/litespeedtech/lsquic/compare/v4.8.2...v4.9.0 and the fixing pull request https://github.com/litespeedtech/lsquic/pull/666. The 4.9.0 release adds the es_max_header_sets engine setting (documented in docs/apiref.rst and include/lsquic.h) which caps completed header sets buffered per HTTP stream while awaiting application processing; it defaults to LSQUIC_DF_MAX_HEADER_SETS_SERVER (1) in server mode and LSQUIC_DF_MAX_HEADER_SETS_CLIENT (2) in client mode, must be greater than zero or engine settings validation fails, and can be tuned via the -o max_header_sets=N program option or by assigning settings->es_max_header_sets directly. When the limit is reached, HTTP/3 parsing on that stream is suspended until the application claims enough header sets to drop below the cap, so raising the value trades memory headroom for stream throughput under legitimate high-concurrency header load. For deployments that cannot move to 4.9.0 immediately, the same cap must be enforced in the application layer by claiming buffered header sets promptly and by bounding how much unclaimed header data the endpoint will queue; there is no peer-side setting that mitigates this, since the limit is local to the receiving endpoint. Where lsquic cannot be patched or constrained, the remaining option is to reduce reachability of the HTTP/3 listener (restrict UDP/QUIC ingress to known peers), accepting the loss of public HTTP/3 service.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
lsquic is LiteSpeed's QUIC and HTTP/3 implementation, used to terminate IETF QUIC (HTTP/3) connections over UDP. HTTP/3 carries request and response metadata as QPACK-encoded header blocks; the receiver decodes each block into a header set and queues completed header sets for the application to claim. The QPACK dynamic table makes a single encoded block cheap for the sender relative to the number of header sets it produces, so a small amount of attacker traffic can yield a much larger number of buffered header sets on the receiving side - the amplification referenced in the CVE. Header handling interacts with the peer-advertised es_max_header_list_size limit and with header_out_dynamic_entry in the encoder path, but the core defect is CWE-770 (Allocation of Resources Without Limits or Throttling): the receive path tracked completed header sets in an unbounded queue, so memory grew with attacker-controlled input. The 4.9.0 fix introduces es_max_header_sets, a purely local receive-side limit with no peer-negotiated counterpart, that suspends HTTP/3 parsing on a stream once the queue reaches the cap (defaults: 1 header set in server mode, 2 in client mode via LSQUIC_DF_MAX_HEADER_SETS_SERVER / LSQUIC_DF_MAX_HEADER_SETS_CLIENT); the value must be greater than zero modulo the new validation, and receiving an extra gQUIC header set beyond the limit is treated as a connection error.
Know when Lsquic gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Remote, unauthenticated HTTP/3 request flood with no user interaction (AV:N/AC:L/PR:N/UI:N); memory-exhaustion DoS gives A:H with no confidentiality or integrity impact.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
2DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-115482 is a high-severity flaw in LiteSpeed's lsquic HTTP/3 stack that allows unauthenticated remote attackers to exhaust server or client memory and cause denial-of-service. Any organization exposing HTTP/3 over UDP/QUIC using lsquic versions before 4.9.0 is affected, including production web servers, load balancers, and client applications, potentially leading to service outages and operational disruption. Leadership should prioritize remediation because the attack requires no credentials and can be launched remotely with default configurations.
No vendor-released patch identified at time of analysis; interim mitigations include disabling HTTP/3 over QUIC, implementing rate limiting or connection limits on UDP/QUIC traffic, and monitoring for abnormal memory consumption.
Threat Intelligence Overview
NVD
CVE.org
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
In LiteSpeed QUIC (LSQUIC) Library before 4.0.4, DCID validation is mishandled. Rated critical severity (CVSS 9.8), this
liblsquic/lsquic_qenc_hdl.c in LiteSpeed QUIC (aka LSQUIC) before 3.1.0 mishandles MAX_TABLE_CAPACITY. Rated critical se
LiteSpeed QUIC (LSQUIC) Library before 4.3.1 has an lsquic_engine_packet_in memory leak. Rated medium severity (CVSS 5.3
Exploit-DB