CVE-2026-119134 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 caps component-model resource handle tables only per component instance and does not charge handle allocations to any ResourceLimiter or StoreLimits. A malicious guest can repeatedly call resource.new and instantiate sub-components to exceed the per-instance cap many times over, causing unbounded host memory growth.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Wasmtime versions prior to 36.0.18, 37.0.0 before 49.0.6, and 49.0.0 before 49.0.3 represents a critical failure in resource management within the WebAssembly component model implementation. Specifically, the runtime incorrectly caps handle tables on a per-component instance basis rather than enforcing limits at the store level or through explicit limiter interfaces. This architectural oversight allows malicious guest code to bypass intended memory constraints by exploiting the isolation boundaries between component instances. The core technical flaw lies in how resource handles are allocated and tracked; while individual components have their own handle table caps, these allocations do not contribute to global ResourceLimiter or StoreLimits configurations that are designed to protect host resources from unbounded consumption.
From a technical perspective, this misconfiguration enables an attacker to perform repeated calls to the resource.new function, which creates new resource handles within the guest environment. By instantiating sub-components repeatedly, the malicious code can effectively multiply its capacity to allocate handles far beyond what was originally intended by the host application or sandbox configuration. Each instantiation of a sub-component resets or operates independently regarding handle table limits, allowing the attacker to accumulate resources across multiple instances without triggering any global memory thresholds. This results in unbounded growth of host-side memory as each allocated resource consumes system memory that is not accounted for in standard limiting mechanisms.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through excessive memory consumption. An attacker who can execute arbitrary WebAssembly code within the Wasmtime runtime can trigger rapid and uncontrolled memory allocation on the host machine. This leads to resource exhaustion, potentially causing the host application or system to crash due to out-of-memory errors. In cloud-native environments where multiple tenants might share a single Wasmtime instance, this vulnerability could allow one tenant to degrade service availability for others by consuming all available heap space through handle table abuse. The lack of proper accounting means that traditional monitoring tools relying on standard memory limits may fail to detect the anomaly until significant damage has occurred.
This issue aligns with CWE-787: Out-of-bounds Write and CWE-400: Uncontrolled Resource Consumption, as it involves improper handling of resource allocation leading to system instability. In terms of MITRE ATT&CK mapping, this vulnerability facilitates techniques associated with T1496: Resource Hijacking, where an adversary uses computing resources for their own purposes, often resulting in denial-of-service conditions by exhausting host resources. The exploitation vector typically requires the ability to execute untrusted WebAssembly code that interacts with component model APIs, making it relevant to scenarios involving plugin architectures or sandboxed execution environments.
Mitigation strategies must focus on upgrading Wasmtime to patched versions where 36.0.18, 49.0.6, and 49.0.3 are the respective minimum safe releases for their major branches. For organizations unable to immediately upgrade, implementing strict limits at the store level using StoreLimits is recommended as a compensating control. Developers should ensure that all resource allocations are explicitly tied to global limiters rather than relying solely on per-instance caps. Additionally, monitoring host memory usage during WebAssembly execution can help detect anomalous patterns indicative of this exploitation technique. Regular security audits of component model implementations and adherence to least-privilege principles in sandbox configuration will further reduce the risk surface associated with such resource management flaws.