What is the CVSS score of CVE-2026-44453?

CVE-2026-44453 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Which versions of h2o are affected by CVE-2026-44453?

The h2o HTTP server is vulnerable to remote denial-of-service attacks that can crash servers without authentication.

How to fix or mitigate CVE-2026-44453?

Within 24 hours, identify all systems running h2o and flag instances on musl libc environments (Alpine, containerized deployments); implement monitoring for server crashes. Within 7 days, evaluate upgrade pathways (upstream commit 6b5370d contains the fix), implement interim WAF/IDS rules to limit static file request sizes and paths, and track vendor release status. Within 30 days, deploy available patches or alternative HTTP server, validate in production, and confirm availability monitoring is detecting anomalies.

h2o CVE-2026-44453

HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-07-16 security-advisories@github.com

Denial Of Service H2O

7.5

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

5.9 MEDIUM

Network, unauthenticated, no interaction, availability-only crash; AC:H because exploitation depends on the non-default musl-libc build with a 128KB stack.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 16, 2026 - 23:30 vuln.today

CVE Published

Jul 16, 2026 - 23:16 cve.org

HIGH 7.5

DescriptionCVE.org

h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit 6b5370d, h2o is vulnerable to a Denial of Service attack when calling alloca under certain conditions. When serving static files, h2o builds the file path on stack, by calling alloca. The maximum size of the memory allocated using alloca can be as huge as ~600KB, which exceeds the default pthread stack size used by musl libc (128KB). If the amount of memory allocated by alloca exceeds the stack size, the h2o server crashes with a segmentation fault, while it tries to touch the guard page. This issue has been fixed by commit 6b5370d.

AnalysisAI

Denial of service in the h2o HTTP server (all versions prior to commit 6b5370d) allows remote unauthenticated attackers to crash the server by requesting static files whose on-stack path construction via alloca can reach ~600KB, exceeding musl libc's default 128KB pthread stack and triggering a guard-page segmentation fault. The flaw is a CWE-770 uncontrolled resource allocation issue affecting availability only (CVSS 7.5, A:H). There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but exploitation is trivial where h2o is built against musl libc.

Technical ContextAI

h2o is a high-performance open-source HTTP server supporting HTTP/1.x, HTTP/2, and HTTP/3, sometimes deployed at CDN/edge scale. When serving static files it constructs the target filesystem path on the call stack using alloca(), a function that allocates memory in the current stack frame without bounds enforcement. Because the computed path size can grow to roughly 600KB, it exceeds the 128KB default per-thread stack size that musl libc allocates (glibc typically uses a much larger 8MB main-thread stack, so glibc builds are far less likely to be affected). The root cause maps to CWE-770 (Allocation of Resources Without Limits or Throttling): the code does not cap or throttle the stack allocation size against available stack space, so touching the stack guard page faults and terminates the process. No CPE data was provided; affected product identification relies on the description and the h2o GHSA advisory.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the change from commit 6b5370d9d09fcf83aa7620ddf77de1954a192181 (https://github.com/h2o/h2o/commit/6b5370d9d09fcf83aa7620ddf77de1954a192181) by rebuilding h2o from a source tree that includes it, or upgrade to a distribution/package build that incorporates it once released. Review the security advisory at https://github.com/h2o/h2o/security/advisories/GHSA-rf9v-m59p-mq84 for maintainer guidance. Until patched, the most effective compensating control for musl-based builds is to increase the per-thread stack size (raising the pthread stack limit above the ~600KB alloca ceiling), or rebuild against glibc, which uses a larger default stack; both change runtime memory behavior and should be validated under load. As an interim network control, place a reverse proxy or WAF in front of h2o to reject requests with excessively long paths targeting static-file handlers, accepting that legitimate long paths would also be blocked.