CVE-2026-115390 in Wasmtime
Summary
by MITRE • 10/22/2026
Wasmtime 47.0.0 before 48.0.3 and 49.0.0 before 49.0.1 contains a fuel accounting flaw in Cranelift-compiled call_ref and try_table catch paths. Malicious guests can reset consumed fuel after calls to run exponentially long on linear fuel, evading timeouts and periodic yields for denial of service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Wasmtime versions prior to 48.0.3 and 49.0.1 represents a critical failure in the resource accounting mechanisms within the Cranelift backend, specifically affecting the execution paths associated with call_ref instructions and try_table catch blocks. WebAssembly engines rely on a fuel-based system to prevent infinite loops and ensure predictable execution times, which is essential for maintaining stability in sandboxed environments where untrusted code may be executed. In this specific flaw, the internal state tracking consumed fuel fails to correctly persist or update during certain control flow transitions involving function calls through references and exception handling mechanisms within try-catch structures. This discrepancy allows a malicious guest module to manipulate the execution context such that the accumulated fuel consumption is effectively reset or ignored after these specific operations occur.
From a technical perspective, the core issue lies in how Cranelift handles the transition of control flow when invoking functions via call_ref and processing exceptions caught by try_table blocks. When a WebAssembly program invokes a function through a reference type or triggers an exception that is subsequently caught within a try block, the engine's fuel accounting logic does not properly account for the computational work performed during these transitions. Consequently, instead of consuming linear amounts of fuel proportional to the actual execution steps taken, the system may reset its internal counters or fail to increment them as expected. This allows attackers to construct payloads that trigger these specific code paths repeatedly while keeping their perceived resource usage artificially low, thereby bypassing the engine's built-in safeguards against excessive computation.
The operational impact of this vulnerability is significant, primarily manifesting as a denial of service condition for hosts running untrusted WebAssembly modules. Because malicious actors can evade timeouts and periodic yields designed to interrupt long-running processes, they can cause the host application or server to hang indefinitely while consuming substantial CPU resources without triggering the expected termination signals. This undermines the fundamental security guarantee provided by WebAssembly sandboxes, which is isolation from resource exhaustion attacks. In cloud-native environments or web applications that compile and execute user-supplied code using Wasmtime, this flaw could be exploited to degrade service availability for other tenants or users sharing the same infrastructure resources.
This vulnerability aligns with CWE-400, Uncontrolled Resource Consumption, as it allows an attacker to cause a denial of service by exhausting system resources through inefficient accounting rather than direct resource allocation flaws. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK techniques, this behavior resembles T1496, Resource Hijacking, where the adversary leverages compromised or untrusted code to consume computational cycles for disruptive purposes. The exploitation vector typically involves crafting malicious WebAssembly binaries that carefully sequence call_ref and try_table operations to trigger the fuel reset condition repeatedly until the host system becomes unresponsive.
Mitigation strategies focus primarily on upgrading the Wasmtime runtime environment immediately to version 48.0.3 or later, which includes patches correcting the fuel accounting logic in these specific execution paths. For environments where immediate patching is not feasible, implementing strict limits on module complexity and execution depth at the application layer can provide a secondary defense-in-depth measure. Additionally, developers should ensure that any WebAssembly modules executed are validated against known malicious patterns and restricted to minimal required capabilities to reduce the attack surface available for such exploitation attempts. Regular updates of underlying runtime components remain the most effective control against evolving vulnerabilities in sandboxed execution environments.