CVE-2026-119131 in Wasmtime
Summary
by MITRE • 10/29/2026
Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability in wasmtime-wasi-http that lets guests crash the host by sending long request URLs. Guests can use set-path-with-query with a '?' after byte 65535, overflowing a u16 index in the http crate and triggering a host panic.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The identified vulnerability resides within the wasmtime-wasi-http component of Wasmtime versions prior to 48.0.6 and between 49.0.0 and 49.0.3, representing a critical denial of service flaw that allows untrusted WebAssembly guests to crash the host runtime environment. This issue stems from an improper handling of input data length during URL path construction, specifically when utilizing the set-path-with-query function. The core technical failure is a classic integer overflow vulnerability where a u16 index used for tracking byte positions fails to account for inputs exceeding its maximum capacity of 65535 bytes. When a guest module constructs a request with a query string containing a question mark character after the first 65535 bytes, the internal counter wraps around due to the unsigned sixteen-bit integer limitation. This wraparound results in an invalid memory index being passed to underlying HTTP crate functions, which subsequently triggers a panic condition within the host process rather than gracefully rejecting or truncating the oversized input.
From a technical perspective, this flaw aligns with CWE-190 Integer Overflow or Wraparound and CWE-20 Improper Input Validation as defined by industry standards for software security weaknesses. The vulnerability is particularly severe because it bypasses typical boundary checks that might otherwise limit request size in web server contexts. In the WebAssembly ecosystem, guests are expected to operate within a sandboxed environment where they cannot directly crash the host system. However, this specific implementation detail in wasmtime-wasi-http allows guest code to exert control over low-level memory indexing operations through high-level API calls like set-path-with-query. The presence of the query delimiter after an excessively long path segment serves as the trigger mechanism that exposes the underlying buffer management logic flaw. This behavior violates the fundamental isolation guarantees provided by WebAssembly runtimes, effectively turning a standard HTTP request construction operation into a vector for host compromise via denial of service.
The operational impact of this vulnerability is significant for any deployment relying on Wasmtime to execute untrusted or semi-trusted web assembly modules that interact with external services through WASI HTTP APIs. An attacker who can control the input parameters passed to these functions, even indirectly through user-supplied data processed by the guest module, can cause immediate termination of the host process. This leads to service disruption for all concurrent users and processes sharing the same Wasmtime instance. In cloud-native or serverless environments where WebAssembly is increasingly used as a secure execution sandbox, such crashes undermine trust in the platform's reliability and security posture. The lack of graceful error handling means that recovery requires restarting the host application, which may involve significant downtime depending on the deployment architecture and failover mechanisms in place.
Mitigation strategies must prioritize immediate upgrading to patched versions of Wasmtime, specifically version 48.0.6 or later for the older branch, or version 49.0.3 and above for the newer release line. These updates contain fixes that enforce proper bounds checking on URL path lengths before indexing operations occur, ensuring that inputs exceeding safe limits are rejected with appropriate error codes rather than causing memory corruption or panics. For environments where upgrading is not immediately feasible, defensive coding practices within guest modules should be adopted to validate and truncate input data before passing it to WASI HTTP functions. Additionally, implementing network-level rate limiting or request size restrictions at the proxy layer can provide an additional defense-in-depth measure by preventing excessively long URLs from reaching the Wasmtime runtime in the first place. Continuous monitoring for unusual host process restarts may also help detect exploitation attempts of this vulnerability before widespread impact occurs.