CVE-2026-119130 in Wasmtime
Summary
by MITRE • 10/29/2026
Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 does not verify that set-path-with-query values in wasmtime-wasi-http are paths, so absolute-form URLs are written verbatim as the HTTP/1.1 request target while the connection uses the allowed authority. A malicious guest can supply an absolute URL that a forward proxy or gateway at that authority honors, reaching hosts disallowed by embedder filtering policies.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Wasmtime versions prior to 36.0.18, 37.0.0 through 48.0.6, and 49.0.0 through 49.0.3 represents a critical security flaw within the wasmtime-wasi-http implementation regarding URL validation logic. Specifically, the system fails to properly verify that values designated as set-path-with-query are strictly paths rather than full absolute URLs. This oversight allows malicious WebAssembly guests to supply absolute-form Uniform Resource Locators instead of relative or path-only requests. When such a request is processed, Wasmtime writes these absolute URLs verbatim into the HTTP/1.1 request target field while simultaneously utilizing the allowed authority for the underlying network connection.
This architectural inconsistency creates a significant bypass mechanism for access control policies enforced by embedders. In standard HTTP/1.1 operations using an origin-form or path-and-query form, the host header and the request line align in terms of destination intent. However, when an absolute URL is placed directly into the request target without stripping the authority component, intermediate network devices such as forward proxies or gateways may interpret the request based on the explicit hostname contained within that absolute URL rather than the connection's actual destination. Consequently, a malicious guest can craft requests that appear to be directed at allowed hosts but are actually routed by proxy infrastructure to disallowed external destinations.
The operational impact of this vulnerability is severe for environments relying on Wasmtime as a sandboxed execution environment with strict egress filtering policies. Attackers who gain the ability to execute arbitrary WebAssembly code within these constrained contexts can exploit this flaw to exfiltrate data, access internal services that are not exposed to the public internet, or pivot through trusted network boundaries. The vulnerability effectively neutralizes host-based allowlists and proxy configurations designed to restrict outbound connections from untrusted workloads, thereby compromising the isolation guarantees provided by the WebAssembly sandbox model.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the application fails to validate that user-supplied input conforms to expected structural constraints before processing it for network transmission. Furthermore, in the context of the MITRE ATT&CK framework, this behavior facilitates lateral movement and command-and-control activities by allowing an attacker to bypass network segmentation controls via proxy abuse techniques similar to those described under T1090 Proxy Abuse or more specifically leveraging misconfigured HTTP routing logic akin to aspects found in request smuggling scenarios.
Mitigation strategies must prioritize immediate upgrading of the Wasmtime runtime to version 36.0.18, 48.0.6, or 49.0.3 and later, where this validation logic has been corrected to ensure that path-only values are strictly enforced for set-path-with-query operations. Embedders should also implement defense-in-depth measures by validating HTTP request targets at the proxy level rather than relying solely on application-level filtering within the WebAssembly environment. Additionally, developers integrating Wasmtime into their applications should review network policies to ensure that even if a bypass occurs, downstream security controls such as strict egress firewalls and zero-trust architectures can prevent unauthorized access to sensitive internal resources.