CVE-2026-44433: QUIC flow-control bug enables memory

CISO Take

A flaw in Quicly, the QUIC protocol implementation used by the H2O HTTP server, lets a remote peer send a single-byte STREAM frame at the maximum permitted offset to inflate flow-control credit and force the server to pre-allocate large out-of-order receive buffers, exhausting memory with only a handful of packets — under H2O's default settings this roughly quadruples per-connection memory usage. This is not an AI-specific vulnerability: it affects any deployment terminating QUIC/HTTP-3 traffic through H2O, including API gateways or reverse proxies that happen to front LLM inference endpoints or AI-enabled web services. Exploitation likelihood is low (EPSS 0.00247, top 84th percentile — not a top-tier priority), there's no CISA KEV listing, no public PoC, and no Nuclei template, and the CVSS 5.3 (availability-only, no confidentiality/integrity impact) reflects a nuisance-DoS profile rather than a critical outage risk. Action: patch to the version incorporating commit 8b178e6 (or later) on any H2O/Quicly deployment, regardless of whether it's AI-adjacent; if H2O fronts an inference API or agent backend, monitor for anomalous per-connection memory growth as a detection signal in the interim.

Sources: NVD EPSS GitHub Advisory

What is the risk?

Network-exploitable (AV:N), low attack complexity, no privileges or user interaction required — but impact is limited to availability (CVSS 3.1 A:L, no C/I impact) and severity is capped at Medium (5.3). Exploitation probability is low per EPSS (0.24%, 84th percentile), there is no evidence of active exploitation, no CISA KEV entry, and no public exploit code or scanner template exists. This is a classic resource-exhaustion/DoS bug in a general-purpose network protocol library, not an AI-model-targeting vulnerability — its relevance to AI/ML systems is entirely indirect, contingent on whether H2O/Quicly happens to sit in front of an AI service's traffic path.

How does the attack unfold?

Initial Access

Attacker establishes a QUIC connection to a public-facing H2O/Quicly-terminated endpoint, requiring no authentication or user interaction.

Exploitation

Attacker sends a minimal STREAM frame (one byte at the largest permitted offset) to obtain excess flow-control credit and trigger oversized receive-buffer allocation.

Impact

Repeated low-volume packets across streams/connections exhaust server memory (up to ~4x normal per-connection usage under H2O defaults), degrading or crashing the service — including any AI inference or agent backend it fronts.

AML.T0029

Initial Access

Attacker establishes a QUIC connection to a public-facing H2O/Quicly-terminated endpoint, requiring no authentication or user interaction.

Exploitation

Attacker sends a minimal STREAM frame (one byte at the largest permitted offset) to obtain excess flow-control credit and trigger oversized receive-buffer allocation.

Impact

Repeated low-volume packets across streams/connections exhaust server memory (up to ~4x normal per-connection usage under H2O defaults), degrading or crashing the service — including any AI inference or agent backend it fronts.

AML.T0029

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 21% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

Upgrade Quicly to the version containing fix commit 8b178e6 (https://github.com/h2o/quicly/commit/8b178e692c51a3b1031612ef89f03a53aac63c15) and update any H2O HTTP server build that bundles Quicly. If immediate patching isn't possible, reduce exposure by capping stream concurrency per connection and/or reviewing the application's out-of-order receive-buffer allocation strategy to avoid pre-allocating up to the largest offset received. Detection: monitor per-connection and per-process memory consumption on QUIC/HTTP-3-terminating edge servers for anomalous spikes correlated with a small number of inbound packets; alert on connections triggering disproportionate buffer growth relative to bytes actually transferred.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS API AML.T0029 - Denial of AI Service

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience

Frequently Asked Questions

What is CVE-2026-44433?

A flaw in Quicly, the QUIC protocol implementation used by the H2O HTTP server, lets a remote peer send a single-byte STREAM frame at the maximum permitted offset to inflate flow-control credit and force the server to pre-allocate large out-of-order receive buffers, exhausting memory with only a handful of packets — under H2O's default settings this roughly quadruples per-connection memory usage. This is not an AI-specific vulnerability: it affects any deployment terminating QUIC/HTTP-3 traffic through H2O, including API gateways or reverse proxies that happen to front LLM inference endpoints or AI-enabled web services. Exploitation likelihood is low (EPSS 0.00247, top 84th percentile — not a top-tier priority), there's no CISA KEV listing, no public PoC, and no Nuclei template, and the CVSS 5.3 (availability-only, no confidentiality/integrity impact) reflects a nuisance-DoS profile rather than a critical outage risk. Action: patch to the version incorporating commit 8b178e6 (or later) on any H2O/Quicly deployment, regardless of whether it's AI-adjacent; if H2O fronts an inference API or agent backend, monitor for anomalous per-connection memory growth as a detection signal in the interim.

Is CVE-2026-44433 actively exploited?

No confirmed active exploitation of CVE-2026-44433 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-44433?

Upgrade Quicly to the version containing fix commit 8b178e6 (https://github.com/h2o/quicly/commit/8b178e692c51a3b1031612ef89f03a53aac63c15) and update any H2O HTTP server build that bundles Quicly. If immediate patching isn't possible, reduce exposure by capping stream concurrency per connection and/or reviewing the application's out-of-order receive-buffer allocation strategy to avoid pre-allocating up to the largest offset received. Detection: monitor per-connection and per-process memory consumption on QUIC/HTTP-3-terminating edge servers for anomalous spikes correlated with a small number of inbound packets; alert on connections triggering disproportionate buffer growth relative to bytes actually transferred.

What systems are affected by CVE-2026-44433?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference API gateways (only if fronted by H2O/Quicly).

What is the CVSS score for CVE-2026-44433?

CVE-2026-44433 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.28%.

What is the AI security impact?

Affected AI Architectures

model servinginference API gateways (only if fronted by H2O/Quicly)

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

Quicly is an IETF QUIC protocol implementation intended primarily for use within the H2O HTTP server. Prior to commit 8b178e6, an adversarial peer could send a STREAM frame carrying just one byte at the largest offset being permitted to obtain additional flow control credit, which under certain circumstances could lead to a Denial of Service. Assuming the application prepares a receive buffer for storing all data that arrive out-of-order, up to the largest offset being received, this behavior could lead to the application allocating large amount of memory with the peer sending only a handful of packets, resulting in memory exhaustion. In addition to the receive buffer allocation strategy, the severity of this vulnerability depends on how the application controls the stream concurrency. In case of the H2O HTTP server, under its default setting, this bug increases the maximum amount of memory allocated per connection by about 4 times. This issue has been fixed by commit 8b178e6.

Exploitation Scenario

An adversary opens a QUIC connection to an H2O-fronted service (which may be an AI inference API, RAG gateway, or general web app) and sends a STREAM frame containing a single byte at the maximum permitted stream offset. This tricks the server into granting additional flow-control credit and, if the application pre-allocates a receive buffer sized to the largest offset seen, forces allocation of a large memory buffer per stream. By repeating this across multiple streams/connections with minimal packet volume, the attacker drives memory exhaustion on the server process, degrading or crashing the service — a low-cost, low-skill denial-of-service against whatever sits behind the H2O/Quicly edge, including any AI-service endpoints it happens to proxy.

Weaknesses (CWE)

CWE-400 Uncontrolled Resource Consumption Primary CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-400 Uncontrolled Resource Consumption CWE-770 Allocation of Resources Without Limits or Throttling

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.