CVE-2026-44216: Wasmtime: Panic when allocating a table exceeding the size of the host's address space
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.
Patches
Wasmtime 36.0.8, 43.0.2, and 44.0.1 have all been released which fixes this issue.
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.
Other sources
Wasmtime is a runtime for WebAssembly. From 30.0.0 to 36.0.8, 43.0.2, and 44.0.1, 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 vulnerability is fixed in 36.0.8, 43.0.2, and 44.0.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/wasmtimeto a version that resolves this vulnerability.Fixed in 43.0.2 - Upgrade
Upgrade
rust/wasmtimeto a version that resolves this vulnerability.Fixed in 36.0.8 - Upgrade
Upgrade
wasmtimeto a version that resolves this vulnerability.Fixed in 36.0.8 - Upgrade
Upgrade
wasmtimeto a version that resolves this vulnerability.Fixed in 43.0.2 - Upgrade
Upgrade
wasmtimeto a version that resolves this vulnerability.Fixed in 44.0.1 - Configuration
Work around the issue by configuring Wasmtime to use the pooling allocator instead of the on-demand instance allocator (the default), since the bug is only present for the on-demand instance allocator.
Wasmtime allocator instance = pooling allocator - Configuration
Work around the issue by disabling the `memory64` WebAssembly feature (it is on-by-default), since this bug requires `memory64` to be enabled.
Wasmtime memory64 WebAssembly feature = disabled
Event History
Frequently Asked Questions
What is the severity of CVE-2026-44216?
The severity of CVE-2026-44216 is considered significant due to the potential for application crashes when allocating large tables.
How do I fix CVE-2026-44216?
To fix CVE-2026-44216, upgrade Wasmtime to version 43.0.2 or later if you are using versions between 37.0.0 and 43.0.2.
What is affected by CVE-2026-44216?
CVE-2026-44216 affects Wasmtime versions between 30.0.0 and 36.0.8 as well as versions between 37.0.0 and 43.0.2.
What can happen if CVE-2026-44216 is exploited?
Exploitation of CVE-2026-44216 can result in a panic and crash of applications that allocate excessively large WebAssembly tables.
Is CVE-2026-44216 related to WebAssembly?
Yes, CVE-2026-44216 is specifically related to the allocation logic of WebAssembly tables in the Wasmtime runtime.