CVE-2026-90648 in wabt
Summary
by MITRE • 09/13/2026
wasm2c in WebAssembly wabt through 1.0.41 allows sandbox escape in some situations that primarily involve 32-bit platforms, aka a "table flip" attack. It does not check the return value of calloc() in wasm_rt_allocate_funcref_table() (wasm2c/wasm-rt-impl-tableops.inc). When the funcref table allocation fails, table->data is left NULL while table->size keeps the guest-declared element count; thus, bounds checks still pass and table element accesses resolve to absolute memory addresses (i * sizeof(wasm_rt_funcref_t)). This gives arbitrary read and write of host process memory and - via table.get, table.set, and call_indirect - arbitrary code execution, defeating the isolation that wasm2c exists to provide (a full sandbox escape). wasm2c is used as an in-process sandboxing boundary by RLBox and WasmBoxC, including in Firefox, which compiles the Graphite, Hunspell, Ogg, Expat, and Woff2 libraries via wasm2c to contain untrusted font, media, and XML input. Therefore, sandboxing in these applications is potentially affected. Exploitation requires the funcref table allocation to fail, for example under an address-space limit (RLIMIT_AS), on 32-bit hosts, with vm.overcommit_memory=2, or under memory pressure. On 64-bit Linux with default overcommit the allocation succeeds and the defect is not triggered. The wasm2c memory allocator aborts on calloc failure in the same runtime; the table allocator lacks this abort behavior. This was introduced in commit ab9e0b55 (PR #813).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified as a sandbox escape within the WebAssembly wabt toolchain, specifically affecting wasm2c versions up to 1.0.41, represents a critical failure in memory safety and isolation guarantees for compiled WebAssembly modules. This flaw, colloquially referred to as a table flip attack, stems from an improper handling of dynamic memory allocation failures within the runtime environment. The core technical defect resides in the wasm_rt_allocate_funcref_table function located in the source file wasm2c/wasm-rt-impl-tableops.inc. In this routine, the system attempts to allocate memory for a funcref table using calloc but critically fails to verify whether the allocation was successful before proceeding with subsequent operations. When the operating system or runtime environment is unable to satisfy the memory request, calloc returns NULL. However, the code does not check this return value and instead proceeds to initialize the table structure such that the data pointer remains null while the size field retains the guest-declared element count. This inconsistency creates a dangerous state where subsequent bounds checks against the table size pass because they rely on the size variable rather than validating the validity of the underlying memory buffer.
The operational impact of this flaw is severe, leading to arbitrary read and write access into the host process memory space. Because the data pointer is null but the bounds checking logic assumes a valid array exists based on the declared size, any attempt to access an element in the funcref table results in arithmetic calculation that resolves to absolute memory addresses rather than safe offsets within a allocated buffer. Specifically, accesses are calculated as i multiplied by sizeof(wasm_rt_funcref_t), which effectively allows reading from and writing to arbitrary locations in the host's address space starting near zero. This capability completely undermines the fundamental purpose of wasm2c, which is to provide an in-process sandboxing boundary for untrusted code. Through standard WebAssembly instructions such as table.get, table.set, and call_indirect, an attacker can leverage this memory corruption primitive to achieve arbitrary code execution on the host system. This constitutes a full sandbox escape, allowing malicious web content or processed files to compromise the integrity of the hosting application.
The risk profile is heavily influenced by platform architecture and operating system configuration. The vulnerability primarily affects 32-bit platforms where address space limits are more restrictive and memory pressure occurs more frequently than on modern 64-bit systems. On 64-bit Linux with default overcommit settings, calloc typically succeeds even under load because the kernel allows virtual address space to exceed physical RAM until actually needed. Consequently, the defect is rarely triggered in these environments. However, exploitation becomes feasible when specific conditions are met that cause allocation failure. These conditions include running on a 32-bit host, enforcing strict address-space limits via RLIMIT_AS, configuring vm.overcommit_memory=2 which enforces strict overcommit accounting, or experiencing significant system memory pressure. The inconsistency is notable because the wasm2c memory allocator correctly aborts upon calloc failure in other contexts, but this specific table allocation routine lacks that protective abort behavior, a discrepancy introduced in commit ab9e0b55 associated with PR #813.
This vulnerability has broad implications for applications and libraries that rely on wasm2c for security isolation. Notably, frameworks such as RLBox and WasmBoxC utilize wasm2c to create sandboxing boundaries within larger host processes. Major software projects including Firefox employ this technique to safely process untrusted inputs by compiling critical libraries like Graphite, Hunspell, Ogg, Expat, and Woff2 into WebAssembly format. These libraries handle sensitive data types such as fonts, media streams, and XML documents. If an attacker can trigger the allocation failure condition within these sandboxes, they can escape the isolation boundary and execute code with the privileges of the host application. This poses a significant threat to browser security models and any other system relying on wasm2c for containment of untrusted content.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes NULL Pointer Dereference, although in this context it is weaponized beyond simple crashes into arbitrary memory access due to the specific way bounds checks are implemented relative to the null pointer arithmetic. It also relates closely to CWE-252, Unchecked Return Value, as the failure to check calloc's return value was the root cause of the state corruption. In terms of offensive security frameworks, this vulnerability facilitates techniques associated with MITRE ATT&CK T1059, Command and Scripting Interpreter, by enabling arbitrary code execution through WebAssembly instructions. It also touches upon privilege escalation concepts as it breaks out of a restricted sandbox environment to gain higher-level access within the host process.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is to upgrade wasm2c to version 1.0.42 or later, where this specific allocation check has been corrected. For environments that cannot immediately update, developers should consider implementing stricter memory limits via RLIMIT_AS if feasible, though this may impact application performance. Additionally, configuring the operating system with vm.overcommit_memory=2 can help ensure that allocations fail predictably rather than succeeding and causing issues later, although this is a systemic change that affects all applications on the host. Application developers using RLBox or WasmBoxC should verify their dependencies are up to date and consider implementing additional runtime checks within custom WebAssembly modules if they must operate in constrained environments where allocation failures might be induced by an attacker. Regular security audits of memory management routines, particularly those involving dynamic allocation for data structures that govern bounds checking logic, are essential to prevent similar discrepancies between declared sizes and actual allocated buffers.