CVE-2026-55213: QPACK alloca overflow crashes HTTP/3

CISO Take

This CVE affects h2o, the C-based HTTP/1.x/2/3 server (github.com/h2o/h2o) — not the H2O.ai machine learning platform that shares the same package name in most catalogs, so first confirm which "h2o" is actually deployed before treating this as an AI/ML incident. The real bug: an unauthenticated remote attacker can send crafted QPACK instructions over HTTP/3 that trigger an on-stack allocation of roughly 800KB via alloca() in lib/http3/qpack.c, which exceeds the default pthread stack size under musl libc (common in slim Alpine containers) and crashes the server with a segfault on the guard page — a clean network-based, no-auth, no-user-interaction denial of service (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). There is no EPSS score published, no CISA KEV listing, no public exploit and no Nuclei template, so there's no evidence of active or imminent exploitation, but the fix commit is public and the crash condition is trivial to script once QUIC/HTTP3 is enabled. If h2o genuinely fronts an AI inference endpoint or API gateway in your stack, upgrade past commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1, and audit whether affected hosts run musl libc (Alpine-based images) where the stack-size mismatch actually manifests.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

Exploitability is high in the technical sense (network-reachable, no authentication, low complexity) but impact is confined to availability — there is no confidentiality or integrity loss, and CVSS reflects this (A:H, C:N, I:N). No CISA KEV listing, no EPSS score, and no public PoC or Nuclei template mean there is currently no evidence of in-the-wild exploitation. The practical blast radius is also narrower than the CVSS score implies: the crash only manifests on musl libc deployments (typically Alpine-based Docker images) whose default pthread stack size is much smaller than glibc's; glibc-based deployments are far less likely to be affected by this specific alloca size. Overall: moderate risk for HTTP/3-enabled h2o deployments on musl-based containers, low risk otherwise, and largely irrelevant to AI/ML security posture beyond generic infrastructure availability.

How does the attack unfold?

Initial Access

Attacker sends a crafted HTTP/3 request with malicious QPACK instructions to a public-facing h2o server, requiring no authentication.

AML.T0049

Trigger

h2o's QPACK handling code in lib/http3/qpack.c calls alloca() to reserve an oversized (~800KB) on-stack buffer for the instruction.

Crash

On musl libc hosts, the allocation exceeds the default pthread stack size and touches the guard page, causing a segmentation fault that kills the h2o process.

Impact

The crash denies availability of the h2o server and any AI service (inference API, RAG backend) sitting behind it, repeatable at will by the attacker.

AML.T0029

Initial Access

Attacker sends a crafted HTTP/3 request with malicious QPACK instructions to a public-facing h2o server, requiring no authentication.

AML.T0049

Trigger

h2o's QPACK handling code in lib/http3/qpack.c calls alloca() to reserve an oversized (~800KB) on-stack buffer for the instruction.

Crash

On musl libc hosts, the allocation exceeds the default pthread stack size and touches the guard page, causing a segmentation fault that kills the h2o process.

Impact

The crash denies availability of the h2o server and any AI service (inference API, RAG backend) sitting behind it, repeatable at will by the attacker.

AML.T0029

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 40% 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

1) Confirm package identity first — verify whether the deployed "h2o" is the HTTP/3 server (github.com/h2o/h2o) rather than H2O.ai's ML package; only the former is affected. 2) Upgrade h2o to a build including commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1 or later. 3) If running on musl libc (Alpine-based container images), either raise the pthread stack size explicitly or migrate to a glibc-based base image until patched. 4) If HTTP/3/QUIC is not a hard requirement, disable it at the h2o config level to remove the attack surface entirely. 5) Detection: monitor for repeated SIGSEGV crashes, container restart loops, or systemd restart counts on h2o processes/workers as an indicator of exploitation attempts against public-facing listeners.

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 Inference AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.9 - AI system operation and monitoring

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption / Denial of Service

Frequently Asked Questions

What is CVE-2026-55213?

This CVE affects h2o, the C-based HTTP/1.x/2/3 server (github.com/h2o/h2o) — not the H2O.ai machine learning platform that shares the same package name in most catalogs, so first confirm which "h2o" is actually deployed before treating this as an AI/ML incident. The real bug: an unauthenticated remote attacker can send crafted QPACK instructions over HTTP/3 that trigger an on-stack allocation of roughly 800KB via alloca() in lib/http3/qpack.c, which exceeds the default pthread stack size under musl libc (common in slim Alpine containers) and crashes the server with a segfault on the guard page — a clean network-based, no-auth, no-user-interaction denial of service (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). There is no EPSS score published, no CISA KEV listing, no public exploit and no Nuclei template, so there's no evidence of active or imminent exploitation, but the fix commit is public and the crash condition is trivial to script once QUIC/HTTP3 is enabled. If h2o genuinely fronts an AI inference endpoint or API gateway in your stack, upgrade past commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1, and audit whether affected hosts run musl libc (Alpine-based images) where the stack-size mismatch actually manifests.

Is CVE-2026-55213 actively exploited?

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

How to fix CVE-2026-55213?

1) Confirm package identity first — verify whether the deployed "h2o" is the HTTP/3 server (github.com/h2o/h2o) rather than H2O.ai's ML package; only the former is affected. 2) Upgrade h2o to a build including commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1 or later. 3) If running on musl libc (Alpine-based container images), either raise the pthread stack size explicitly or migrate to a glibc-based base image until patched. 4) If HTTP/3/QUIC is not a hard requirement, disable it at the h2o config level to remove the attack surface entirely. 5) Detection: monitor for repeated SIGSEGV crashes, container restart loops, or systemd restart counts on h2o processes/workers as an indicator of exploitation attempts against public-facing listeners.

What systems are affected by CVE-2026-55213?

This vulnerability affects the following AI/ML architecture patterns: model serving.

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

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

What is the AI security impact?

Affected AI Architectures

model serving

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.9

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1, when h2o processes a QPACK instruction sent from the peer over HTTP/3, lib/http3/qpack.c might allocate an on-stack buffer as large as approximately 800 KB by calling alloca, which exceeds the default pthread stack size used by musl libc and causes the h2o server to crash with a segmentation fault while touching the guard page. This issue is fixed in commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1.

Exploitation Scenario

An unauthenticated attacker with network access to a public-facing h2o HTTP/3 listener (for example, one fronting an LLM inference API or RAG backend) sends a crafted HTTP/3 request containing malicious QPACK encoder/decoder instructions. The server's QPACK processing code calls alloca() to allocate an oversized on-stack buffer (~800KB); on a musl libc host this exceeds the default thread stack size, and touching the resulting guard page triggers a segmentation fault that kills the worker process. Because no authentication or user interaction is required, the attacker can repeat this at will to sustain a denial-of-service condition against any AI service sitting behind the h2o edge, without needing any AI-specific exploit technique.

Weaknesses (CWE)

CWE-789 Memory Allocation with Excessive Size Value Primary CWE-789 Memory Allocation with Excessive Size Value

CWE-789 — Memory Allocation with Excessive Size Value: The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

[Implementation, Architecture and Design] Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
[Operation] Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Source: MITRE CWE corpus.