CVE-2026-115379 in Wasmtime
Summary
by MITRE • 10/22/2026
Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a missing GC rooting vulnerability that leaves references live across try_call unrooted when compiling Wasm modules. Attackers can supply Wasm modules whose callee triggers garbage collection, leaving stale or dangling references that cause GC heap corruption or incorrect execution.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in Wasmtime versions prior to 48.0.4 and 49.0.2 represents a critical failure in the WebAssembly runtime's memory management logic, specifically concerning garbage collection rooting during function calls. This flaw is classified under CWE-756: Missing Explicit Reference to an Object from GC Root, which indicates that the system failed to maintain a valid reference chain necessary for the garbage collector to correctly identify live objects. In the context of WebAssembly execution, particularly with features like Garbage Collection (GC) enabled, the runtime must ensure that all object references accessible during function invocation are properly rooted. This means they are marked as reachable and protected from being collected while still in use. The specific failure occurs within the try_call mechanism, a construct used for handling exceptions or control flow across module boundaries. When compiling WebAssembly modules, if the callee function triggers garbage collection before all relevant references have been correctly rooted by the caller's context, those references become unrooted prematurely.
From an operational perspective, this technical flaw allows attackers to craft malicious WebAssembly modules that exploit the race condition between reference rooting and garbage collection events. By designing a module where the called function initiates a GC cycle while holding or relying on references that were not properly rooted by the calling context, an attacker can cause these objects to be incorrectly identified as unreachable. Consequently, the garbage collector may reclaim memory associated with live data structures. This leads directly to heap corruption, as subsequent operations attempt to access freed or invalid memory addresses. The impact is severe because it compromises both confidentiality and integrity of the execution environment. In some scenarios, this can lead to incorrect program logic due to corrupted state, while in more complex exploitation cases, it may facilitate arbitrary code execution if the attacker can control how the dangling references are dereferenced after reallocation by other parts of the system.
This vulnerability aligns with ATT&CK technique T1496: Resource Hijacking or potentially T1059: Command and Scripting Interpreter depending on the specific exploitation path, as it involves manipulating runtime resources to achieve unintended execution states. The lack of explicit rooting violates fundamental principles of safe memory management in managed environments like WebAssembly GC. It highlights a gap in how intermediate representations handle reference lifetimes during complex control flow operations such as try-catch blocks or tail calls that involve garbage collection triggers. Such issues are particularly dangerous because they can be triggered remotely if the Wasmtime instance is exposed to untrusted input, which is common in server-side WebAssembly execution environments like those used for sandboxed plugin systems or secure multi-tenant applications.
Mitigation strategies primarily focus on updating the runtime environment immediately. Organizations running Wasmtime must upgrade to version 48.0.4 or later, and specifically if using the 49.x branch, they should move to 49.0.2 or newer where this rooting logic has been corrected. For developers integrating WebAssembly into their applications, it is crucial to ensure that all dependencies are updated to patched versions of Wasmtime. Additionally, implementing strict input validation for incoming WebAssembly modules can help detect malformed binaries before they reach the execution engine, although this is a secondary defense since the root cause lies within the runtime's internal handling rather than the module structure itself. Security teams should also monitor logs for unusual memory allocation patterns or crashes that might indicate attempted exploitation of similar rooting vulnerabilities in other components of their infrastructure.