CVE-2026-90648: WebAssembly wabt Sandbox Escape RCE

CVE-2026-90648 Overview

CVE-2026-90648 is a sandbox escape vulnerability in wasm2c, part of the WebAssembly Binary Toolkit (wabt) through version 1.0.41. The flaw stems from an unchecked calloc() return value in wasm_rt_allocate_funcref_table() within wasm2c/wasm-rt-impl-tableops.inc. When the funcref table allocation fails, bounds checks still pass while table accesses resolve to absolute host memory addresses. This gives a guest module arbitrary read, arbitrary write, and arbitrary code execution in the host process, defeating the sandbox boundary that wasm2c provides. The issue affects downstream users such as RLBox and WasmBoxC, including Firefox, which uses wasm2c to sandbox the Graphite, Hunspell, Ogg, Expat, and Woff2 libraries.

Critical Impact

A malicious WebAssembly module can escape the wasm2c sandbox and achieve arbitrary code execution in the host process when the funcref table allocation fails.

Affected Products

• WebAssembly wabt through version 1.0.41 (wasm2c component)
• RLBox and WasmBoxC deployments built on wasm2c
• Firefox builds that sandbox Graphite, Hunspell, Ogg, Expat, and Woff2 via wasm2c

Discovery Timeline

• 2026-09-13 - CVE-2026-90648 published to NVD
• 2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-90648

Vulnerability Analysis

The defect is a missing check on a memory allocation return value [CWE-252] in the wasm2c runtime table allocator. wasm_rt_allocate_funcref_table() calls calloc() to allocate storage for a guest-declared funcref table but does not verify that the returned pointer is non-NULL. On failure, table->data remains NULL while table->size is set to the guest-declared element count.

Because table->size still reflects a valid element count, subsequent runtime bounds checks succeed. Table element accesses then compute their target as table->data + i * sizeof(wasm_rt_funcref_t), which reduces to an absolute host memory address controlled by the guest index i. The guest can read, write, and call arbitrary host addresses through table.get, table.set, and call_indirect.

This behavior contrasts with the wasm2c memory allocator in the same runtime, which aborts on calloc() failure. The regression was introduced in commit ab9e0b55 (PR #813).

Root Cause

The root cause is inconsistent failure handling between the memory allocator and the table allocator in the wasm2c runtime. The table allocator trusts a possibly-NULL pointer, and the runtime treats size as the sole validity signal for bounds checks. NULL plus a small index becomes a low absolute address in the host process rather than an in-sandbox offset.

Attack Vector

Exploitation requires the funcref table allocation to fail. This is reachable on 32-bit hosts, under an address-space limit such as RLIMIT_AS, 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.

A malicious guest module then uses table.get, table.set, and call_indirect on funcref table indices to read and write arbitrary host memory and redirect indirect calls, achieving code execution in the host process. Full technical details are available in the wasm2c-tableflip project and the wabt repository.

Detection Methods for CVE-2026-90648

Indicators of Compromise

• Unexpected crashes or segmentation faults in host processes that link wasm2c-generated code, especially on 32-bit builds or processes constrained by RLIMIT_AS.
• Host process memory reads or writes that map to low virtual addresses consistent with NULL + i * sizeof(wasm_rt_funcref_t).
• Indirect calls from wasm2c code targeting addresses outside expected function pointer regions.

Detection Strategies

• Inventory applications and libraries that embed wabtwasm2c output through RLBox or WasmBoxC, including browser components that sandbox font, media, and XML libraries.
• Instrument wasm_rt_allocate_funcref_table() or wrap calloc() in downstream builds to log allocation failures for funcref tables.
• Review core dumps from sandboxed processes for faults in call_indirect trampolines emitted by wasm2c.

Monitoring Recommendations

• Alert on repeated crashes in processes hosting wasm2c sandboxes, particularly on 32-bit systems and hosts with vm.overcommit_memory=2.
• Track memory pressure and RLIMIT_AS denials on hosts that run wasm2c-based sandboxes, since these conditions are prerequisites for exploitation.
• Correlate untrusted input processing (fonts, media, XML) with process instability in components known to use wasm2c isolation.

How to Mitigate CVE-2026-90648

Immediate Actions Required

• Upgrade to a patched release of wabt once available, or apply a local patch that aborts when calloc() fails in wasm_rt_allocate_funcref_table().
• Rebuild and redeploy any downstream artifacts (RLBox, WasmBoxC, Firefox-derived builds) that were compiled with a vulnerable wasm2c runtime.
• Prioritize remediation on 32-bit hosts and any environment enforcing RLIMIT_AS or vm.overcommit_memory=2.

Patch Information

A patch must ensure wasm_rt_allocate_funcref_table() checks the calloc() return value and aborts on failure, matching the behavior of the wasm2c memory allocator. The regression was introduced in commit ab9e0b55 (PR #813); consumers should track fixes in the wabt repository and review the related Mozilla Bug 1827704 for downstream advisory information.

Workarounds

• Prefer 64-bit hosts with default memory overcommit, where the funcref table allocation succeeds and the defect is not triggered.
• Remove or raise RLIMIT_AS limits and avoid vm.overcommit_memory=2 on processes that embed wasm2c sandboxes, where operationally acceptable.
• Restrict exposure of wasm2c-sandboxed components to untrusted input on 32-bit deployments until patched builds are available.

# Configuration example: verify overcommit setting on Linux hosts running wasm2c sandboxes
sysctl vm.overcommit_memory
# A value of 2 (strict accounting) increases the likelihood of allocation failures
# that can trigger CVE-2026-90648. Confirm downstream builds include the calloc
# return-value check before relaxing this control.