CVE-2026-90648

wasm2c in the WebAssembly Binary Toolkit (wabt) through version 1.0.41 fails to check the return value of calloc() in wasm_rt_allocate_funcref_table(), leaving the funcref table's data pointer NULL while its size retains the guest-declared element count. Because bounds checks still pass, table element accesses (table.get, table.set, call_indirect) resolve to absolute host memory addresses, giving an attacker arbitrary read/write and ultimately arbitrary code execution outside the sandbox — a complete defeat of the isolation wasm2c exists to provide (a 'table flip' attack). The flaw is triggered only when the table allocation fails, which occurs primarily on 32-bit platforms, under RLIMIT_AS limits, with vm.overcommit_memory=2, or under heavy memory pressure; on 64-bit Linux with default overcommit the allocation succeeds and the bug does not fire. The bug was introduced in commit ab9e0b55 (PR #813) and affects downstream in-process sandboxing frameworks RLBox and WasmBoxC, including Firefox, which uses wasm2c to contain untrusted font, media, and XML parsing (Graphite, Hunspell, Ogg, Expat, Woff2). No public proof of concept exists and the issue is not listed in CISA's KEV catalog.

What to do: Upgrade wabt/wasm2c to a release newer than 1.0.41 once a fix is available, rebuild and redeploy all wasm2c-generated code and the bundled wasm-rt runtime, and apply browser vendor updates (e.g., from Mozilla) when patched. As an interim mitigation, run wasm2c-based sandboxes on 64-bit hosts with default memory overcommit and avoid strict RLIMIT_AS or vm.overcommit_memory=2 settings where untrusted WebAssembly executes. Audit crash/OOM logs on 32-bit deployments for failed funcref table allocations as a sign of attempted 'table flip' exploitation.