EUVD-2026-30304
GHSA-p8xm-42r7-89xg
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from Vendor (https://github.com/bytecodealliance/wasmtime).
CVSS VectorVendor: https://github.com/bytecodealliance/wasmtime
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Wasmtime's on-demand instance allocator panics when attempting to allocate a WebAssembly table with an extremely large size, triggering arithmetic overflow in checked allocation logic. This denial-of-service condition is exploitable only when the memory64 WebAssembly proposal is enabled (default configuration) and affects versions 30.0.0 through 36.0.7, 37.0.0 through 43.0.1, and unpatched 44.x versions. No public exploit code or active exploitation has been identified; vendor-released patches are available in versions 36.0.8, 43.0.2, and 44.0.1.
Technical ContextAI
Wasmtime is a WebAssembly runtime that supports the memory64 proposal, which extends WebAssembly table sizes from 32-bit to 64-bit address ranges. The vulnerability resides in the on-demand instance allocator's table allocation logic, where checked arithmetic operations (likely using Rust's checked_mul or similar methods) panic on overflow rather than handling the condition gracefully. The memory64 feature enables 64-bit table size specifications, making arithmetic overflow possible when allocation requests exceed the host process's available address space. The pooling allocator, which pre-allocates bounded memory regions, is not affected because it enforces size limits well below the overflow threshold. Root cause is CWE-770 (Allocation of Resources Without Limits or Throttling), specifically unguarded arithmetic in resource allocation paths.
RemediationAI
Upgrade Wasmtime to version 36.0.8, 43.0.2, or 44.0.1 or later, depending on the currently deployed version. No patched version exists for the 44.x line below 44.0.1; users on 44.0.0 must upgrade to 44.0.1. If immediate patching is not feasible, apply one of two concrete workarounds: (1) Switch to the pooling allocator by configuring the Wasmtime InstanceAllocator to use PoolingInstanceAllocator instead of OnDemandInstanceAllocator; this eliminates the overflow condition by enforcing size limits on table allocations. (2) Disable the memory64 WebAssembly proposal by setting Config::memory64(false) in the Wasmtime configuration; this reverts table sizes to the 32-bit range and prevents overflow arithmetic. The pooling allocator workaround is preferred for production deployments as it avoids feature restrictions; however, pooling allocation requires pre-allocated memory pools and may have different performance or resource-usage characteristics depending on workload. Disabling memory64 is suitable only if memory64 tables are not required by instantiated modules. Monitor module sources to prevent instantiation of untrusted WASM modules that declare excessively large tables.
Same technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
| SUSE Linux Enterprise Server 16.0 | Fixed |
| SUSE Linux Enterprise Server 16.1 | Fixed |
| SUSE Linux Enterprise Server for SAP applications 16.0 | Fixed |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Fixed |
| openSUSE Leap 16.0 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today