Summary
Workarounds
Embeddings can switch to using the pooling allocator to work around this issue, or the memory64 WebAssembly proposal can be disabled. Otherwise there is no workaround and users are recommended to upgrade.
Impact
Wasmtime's allocation logic for a WebAssembly table contained checked arithmetic which panicked on overflow. This overflow is possible to trigger, and thus panic, when a table with an extremely large size is allocated. This is possible with the WebAssembly memory64 proposal where tables can have sizes in the 64-bit range as opposed to the previous 32-bit range which would not overflow. The panic happens when attempting to create a very large table, such as when instantiating a WebAssembly module or component.
This bug does not affect the pooling allocator which limits tables sizes to much less than the required amount to trigger the overflow. This bug is only present for the on-demand instance allocator, which is Wasmtime's default allocator. This bug also requires the memory64 WebAssembly feature to be enabled, which is on-by-default.
Panicking in the host process is considered a denial-of-service vector for Wasmtime.
The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Wasmtime 36.0.8, 43.0.2, and 44.0.1 have all been released which fixes this issue.
Frequently Asked Questions
- What is CVE-2026-44216? CVE-2026-44216 is a medium-severity allocation of resources without limits or throttling vulnerability in wasmtime (rust), affecting versions >= 30.0.0, < 36.0.8. It is fixed in 36.0.8, 43.0.2. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
- Which versions of wasmtime are affected by CVE-2026-44216? wasmtime (rust) versions >= 30.0.0, < 36.0.8 is affected.
- Is there a fix for CVE-2026-44216? Yes. CVE-2026-44216 is fixed in 36.0.8, 43.0.2. Upgrade to this version or later.
- Is CVE-2026-44216 exploitable, and should I be worried? Whether CVE-2026-44216 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-44216 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-44216?
- Upgrade
wasmtimeto 36.0.8 or later - Upgrade
wasmtimeto 43.0.2 or later
- Upgrade