CVE-2026-44453: h2o: alloca stack overflow crashes server on request

h2o, a C-based HTTP/1.x/2/3 server sometimes deployed as a reverse proxy or static-file host in front of application backends, builds file paths on the stack via alloca() when serving static files; a crafted request path can force an allocation up to ~600KB, which exceeds the 128KB default pthread stack size under musl libc (common in Alpine-based containers), crashing the process with a segfault when it hits the guard page. This is a remotely triggerable, unauthenticated, single-request denial of service (CVSS 7.5, AV:N/AC:L/PR:N/UI:N) with no confidentiality or integrity impact — but EPSS is very low (0.278%), it is not in CISA KEV, and no public exploit or scanner template exists, so near-term mass exploitation is unlikely. Note for this platform: "h2o" here is the h2o.examp1e.net / github.com/h2o/h2o HTTP server, an unrelated project to H2O.ai's machine-learning library of the same name that we track as an AI package — this CVE has no inherent AI/ML-specific attack surface; it only matters to AI teams that happen to run h2o as a reverse proxy or static-asset server in front of an inference API, RAG UI, or agent dashboard on musl/Alpine containers. Patch to the fix at commit 6b5370d, or as a stopgap increase the pthread stack size (or avoid musl/Alpine deployments of h2o) until upgraded, and monitor for repeated SIGSEGV crash-loops on the h2o process as a detection signal.

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

1) Upgrade h2o to a version that includes the fix at commit 6b5370d (post prior-to-fix state described in the advisory). 2) If immediate upgrade isn't possible, increase the default pthread stack size used by the runtime (particularly relevant on musl libc / Alpine Linux, where the default 128KB is far below the ~600KB alloca can request) or avoid musl-based base images for h2o deployments until patched. 3) Where feasible, restrict or normalize static-file path length/depth at a front-end load balancer or WAF to reduce the chance of triggering the oversized alloca. 4) Detection: monitor for h2o process crash-loops / SIGSEGV signals in container orchestration logs (Kubernetes restart counts, systemd crash logs) as an indicator of attempted or accidental triggering. 5) Confirm via `h2o --version` or package manifest whether any AI-facing reverse proxy or static-asset host in your stack runs h2o, since this is not one of the AI packages in our catalog and won't be auto-flagged by dependency scanners focused on ML libraries.

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

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