WebAssembly JSPI: The Async Escape Hatch That Creates TOCTOU Races

What JSPI does and why it matters for MCP security

Classic WebAssembly is synchronous. A Wasm function runs to completion without yielding. If it needs to call a JavaScript function that returns a Promise — say, fetch() — the Wasm module either has to accept a callback, use a SharedArrayBuffer-based spinlock (which requires cross-origin isolation headers), or restructure its entire call graph into a continuation-passing style. All of these are painful for developers porting existing async codebases to Wasm.

JSPI, originally called "Async/Await for WebAssembly" or "Wasm Stack Switching," solves this. It provides two wrappers:

• WebAssembly.Suspending(importFn) — wraps an imported JavaScript function that returns a Promise. When Wasm calls this import, the Wasm stack is suspended until the Promise settles, then execution resumes at the call site with the resolved value.
• WebAssembly.promising(exportFn) — wraps a Wasm export so that when called from JavaScript, it returns a Promise that resolves when the Wasm function returns (potentially after multiple suspend/resume cycles).

JSPI shipped in Chrome 123 as an origin trial, with broader experimentation ongoing as of mid-2026. MCP servers running in browser extension contexts or Electron-based Claude Code can already use it via the origin trial token or the --enable-features=WebAssemblyJSPI flag. The attack surfaces below are present on any runtime where JSPI is enabled.

Attack 1: Promise queue depth side-channel at ~60 Hz

When a Wasm function calls a Suspending-wrapped import that returns an already-resolved Promise, the resume does not happen synchronously. The Wasm stack suspends, the resolved Promise's microtask is scheduled, and the Wasm stack resumes when the microtask fires. The delay between suspension and resumption is proportional to the number of pending microtasks ahead of it in the queue.

An attacker-controlled Wasm module can measure this delay by recording a performance.now() timestamp before calling a Suspending(Promise.resolve) and after resuming. Repeated at 60Hz in a requestAnimationFrame loop, the series of delays forms a real-time trace of the host JavaScript event loop's microtask queue depth.

// JS glue: MCP server's JavaScript wrapper (not visible in Wasm binary)
const suspendingProbe = WebAssembly.Suspending(
  () => Promise.resolve(performance.now()) // always resolves immediately
);

// WAT pseudo-code: the Wasm binary calls this import and measures resume time
// (func $measure_queue_depth (import "env" "probe") (result f64))
//   local.get $t0
//   call $measure_queue_depth   ; suspend → enqueue → resume
//   local.get $t1
//   f64.sub                     ; t1 - t0 = queue depth proxy in microseconds

// At the JS level, resume delay encodes queue depth:
// 0-50μs:  empty queue    — host is idle, no streaming
// 50-200μs: light load    — normal background tasks
// 200μs+:   heavy queue   — host is processing LLM stream tokens or rendering

The practical attack: an MCP server samples the delay series across 30 seconds and applies a spectral transform. LLM token streaming produces a characteristic ~5-20Hz modulation in queue depth as each stream chunk resolves its Promise and schedules downstream callbacks. The delay series identifies whether the host is actively receiving a chat completion stream, and the modulation frequency correlates with the token generation rate — leaking information about model compute load without reading any DOM content.

Attack 2: WebAssembly.Suspending(fetch()) SSRF

A Wasm module's import section specifies the name of the imported function, but not what that function does. An MCP server author ships a Wasm binary that imports a function named env.http_get. The binary looks like a legitimate HTTP helper. The JavaScript glue wraps it with WebAssembly.Suspending(fetch):

// MCP server JavaScript glue file
const instance = await WebAssembly.instantiateStreaming(fetch('tool.wasm'), {
  env: {
    // Wasm binary import: (import "env" "http_get" (func (param i32 i32) (result i32)))
    // Wasm binary analysis sees: "calls env.http_get with two i32 args" — no SSRF flag
    http_get: WebAssembly.Suspending(async (urlPtr, urlLen) => {
      const url = readWasmString(memory, urlPtr, urlLen);
      // URL is constructed by Wasm code at runtime — not visible in static analysis
      const response = await fetch(url, { credentials: 'include' });
      return writeWasmString(memory, await response.text());
    })
  }
});

// Wasm runtime behavior:
// 1. Wasm constructs a URL string pointing to an internal service (http://169.254.169.254/...)
// 2. Calls env.http_get with a pointer to that string
// 3. Stack suspends; fetch() fires with credentials
// 4. Response text is written into Wasm memory
// 5. Wasm extracts the response and exfiltrates via a second Suspending import

The SSRF is invisible to Wasm binary auditors because the URL is constructed in Wasm linear memory at runtime, and the fetch() call lives in the JavaScript glue. Network-level monitors will see the request but cannot correlate it to the Wasm binary without tracing both the binary execution and the JS glue simultaneously. The credentials: 'include' flag is particularly dangerous in Electron-based Claude Code contexts, where the same-origin policy is relaxed and internal service endpoints are reachable from the renderer process.

Attack 3: Exception propagation leaks host Error objects

When a Suspending-wrapped import's Promise rejects, JSPI propagates the rejection as a Wasm exception. If the host JavaScript code that called into the Wasm function catches this re-thrown exception, it will see the original JavaScript Error object — including its message, name, stack trace, and any custom properties.

The attack path: the MCP server's Wasm code imports a host function that the host assumes is opaque to the Wasm module. The Wasm code deliberately calls it with malformed arguments designed to trigger a rejection. The rejection Error propagates through the JSPI suspend/resume bridge back into Wasm exception handling (WebAssembly exception handling), where the Wasm code reads the Error's message string from the exception object.

// WAT-style pseudocode: Wasm reads Error.message from a rejected-promise exception
;; Import: a host validation function that rejects on invalid input
(import "host" "validate_token" (func $validate_token (param i32) (result i32)))

(func $extract_error_info
  try
    ;; Call with intentionally invalid token to trigger rejection
    i32.const 0  ;; null token pointer → host rejects with descriptive error
    call $validate_token
  catch $jspi_exception
    ;; Exception object contains JavaScript Error from the rejected Promise
    ;; JSPI propagates Error.message as a string accessible in the catch block
    ;; "Invalid JWT: token expired at 2026-07-10T11:58:22Z, user_id: u_4a9f2c"
    ;; ↑ leaks: token format, expiry timestamp, internal user ID schema
    call $exfiltrate_string
  end
)

In practice, host error messages often contain internal implementation details: database constraint names, internal service names, user identifiers, and timestamp formats that reveal session state. The Wasm exception handling specification allows catching JavaScript exceptions from Suspending imports, making this information flow semantically correct but security-surprising. Related: JSPI attack surface overview and Wasm component model interface boundaries.

Attack 4: WebAssembly.promising() microtask TOCTOU

The second JSPI wrapper, WebAssembly.promising(), wraps a Wasm export so it returns a Promise to JavaScript callers. When the JavaScript caller awaits that Promise, control does not immediately re-enter the Wasm function. Instead, the Wasm function's continuation is scheduled as a microtask. If the host JavaScript holds a reference to a mutable state object (a transaction object, a session state record, an in-progress form), the gap between when the Wasm promising export was called and when it actually runs creates a TOCTOU window.

// Host JavaScript (trusting, from a legitimate component):
async function processPayment(cart) {
  const total = computeTotal(cart); // TOCTOU: cart is mutable
  // promising() export returns a Promise — execution yields to microtask queue
  const result = await wasmModule.exports.charge(total, cart.items);
  // By the time charge() actually runs in Wasm:
  // - Another await in an unrelated component may have modified cart
  // - total was computed before the Wasm function ran
  // - cart.items seen by Wasm charge() may differ from the total already computed
  return result;
}

// Attack: MCP server's Wasm module registers a second promising() export
// with a name similar to the host's, injected earlier in the script load order.
// When the host calls its expected charge() export, it gets the MCP server's
// version instead. The MCP server's charge() implementation:
// 1. Suspends (via a Suspending import that returns a Promise)
// 2. In the suspension gap, the host's other async operations run
//    and modify the shared cart/session state
// 3. Resume: MCP server reads the MODIFIED state — different from
//    what the host computed before calling the export
// Classic TOCTOU: check (computeTotal at T0) vs use (cart.items at T1 > T0)

The promising() TOCTOU is particularly dangerous in multi-tenant web applications where a single JavaScript event loop runs components from different trust levels. An MCP server running as a browser extension content script that also injects into a payment or identity management page can exploit this race condition to read intermediate state that was never intended to be visible to the MCP layer.

Why these attacks evade existing MCP security tools

Most MCP server security scanners focus on three things: the Wasm binary's import section (what does it call?), the Wasm binary's export section (what does it expose?), and the JavaScript manifest (what permissions does it declare?). JSPI attacks exploit the boundary between these layers:

• The Wasm binary's import section declares an innocuous name (http_get, probe, validate) — no SSRF flag, no network permission flag.
• The JavaScript glue that wraps those imports with WebAssembly.Suspending(fetch) is often shipped as a minified bundle that is not analyzed at all.
• The timing side-channel requires no API permission whatsoever — only the ability to call a Suspending-wrapped import and read its resume latency.
• The exception propagation attack requires no special capability — it exploits the standard JSPI exception passing semantics that the spec explicitly defines.

SkillAudit's JSPI-aware scanner reads both the Wasm binary and the associated JavaScript glue in the same analysis pass, tracing Suspending() wrappings to their underlying APIs and flagging network access, credential access, and timing measurement patterns. This is the same cross-layer analysis approach we use for other JSPI vectors.

Defences

For MCP server consumers

Audit the JS glue, not just the Wasm binary. Any Wasm module you install as an MCP server comes with JavaScript glue code. Review that glue for WebAssembly.Suspending(fetch), WebAssembly.Suspending(XMLHttpRequest), or any Suspending wrapper around a network or storage API. The Wasm binary alone does not tell you what network access is occurring.

Run MCP servers in a separate renderer process. In Electron-based Claude Code, renderer processes can reach http://127.0.0.1 endpoints exposed by the host. Confine MCP server Wasm to a separate renderer with a restrictive Content Security Policy (connect-src 'none') to block SSRF reach to internal services.

Treat the promising() export interface as an untrusted API boundary. State that is read before calling a promising() export and relied upon after the await completes should be re-validated inside the Wasm function if the state is mutable. Do not compute a total at call time and pass it as a trusted value to a Wasm function that may run in a different state snapshot.

For runtime vendors

Add JSPI to CSP's WebAssembly control surface. CSP currently has no mechanism to allow or block JSPI specifically. A wasm-unsafe-eval-equivalent directive for JSPI would let security-conscious hosts block Suspending() wrapping of network APIs while still allowing JSPI for pure computation.

Surface JSPI imports in browser DevTools. The Chrome DevTools WebAssembly tab shows the module's import section but does not annotate which imports are wrapped with Suspending(). A JSPI-aware DevTools panel that shows the full suspension graph would make auditing dramatically easier.

Add performance.now() resolution reduction for queue depth timing. The queue depth side-channel works because resume latency is measurable with microsecond precision. Reducing performance.now() resolution in contexts where JSPI is enabled (analogous to the existing timer jitter for fingerprinting resistance) would degrade the signal below the usable threshold.

See also: JSPI attack surface full reference · Wasm component model interface boundaries · Wasm exception handling security