CVE-2026-6604 [Deep Dive]: WASI Claim vs Reality

The headline claim around CVE-2026-6604 does not survive contact with primary sources. As of May 2, 2026, the NVD entry for CVE-2026-6604 describes an AgentScope SSRF, not a privilege-escalation flaw in a WASI Preview 3 runtime. But the confusion points at a real engineering problem: multi-threaded WebAssembly runtimes are accumulating complex host boundary logic, and that is exactly where concurrency, capabilities, and resource limits can fail.

• CVE-2026-6604 is not officially a WASI or Wasmtime vulnerability.
• Wasmtime shipped WASIp3 support in 43.0.0 on 2026-03-20.
• Wasmtime documents WASIp3 as experimental, unstable, incomplete, and not semver-stable.
• The verified nearby security record is a mix of thread-safety and resource-control issues, not a published Preview 3 privilege-escalation chain.

CVE Summary Card

Vulnerable Code Anatomy

If you strip away the mislabeled CVE number, the security anatomy of a hypothetical WASIp3 multi-threaded privilege-escalation bug is not hard to sketch. It would almost certainly live at one of three seams already visible in public Wasmtime documentation and advisories.

1. Shared memory crossing host trust boundaries

The Wasmtime SharedMemory API exists because ordinary memory views are not safe once multiple agents can mutate the same linear memory in parallel. The docs are blunt: SharedMemory::data exposes &[UnsafeCell<u8>], and normal safe loads and stores are not the right abstraction. That matters because thread-related runtime bugs rarely begin with a dramatic sandbox escape. They begin with a host assuming a stable view of guest-owned bytes that are no longer stable.

2. Guest-controlled allocation on the host side

The more modern the WASI surface, the more often the host needs to materialize guest data as host-side strings, buffers, lists, handles, and component values. Wasmtime added explicit controls here after CVE-2026-27204. The Store::sethostcallfuel API now exists specifically to cap how much data a guest can force the host to allocate per call. If that budget is absent or set far too high, a malicious module can turn a logic flaw into a practical denial of service, and in weaker embeddings a memory-pressure event can destabilize adjacent control paths.

3. Resource bookkeeping and capability lifetime

Component-model runtimes keep tables of resources, handles, and host-managed objects. Wasmtime now exposes ResourceTable::setmaxcapacity because unbounded growth is itself a security problem. In a capability system, the bug is often not “raw code execution.” The bug is “the wrong object stayed live, moved across a trust boundary, or remained reachable after a concurrent state change.” That is the classic precondition for a privilege jump inside a supposedly capability-safe runtime.

use wasmtime::{Config, Engine, Store, SharedMemory, MemoryType};
use wasmtime::component::ResourceTable;
use wasmtime_wasi::{WasiCtx, WasiCtxBuilder, WasiCtxView, WasiView};

struct State {
    ctx: WasiCtx,
    table: ResourceTable,
}

impl WasiView for State {
    fn ctx(&mut self) -> WasiCtxView<'_> {
        WasiCtxView { ctx: &mut self.ctx, table: &mut self.table }
    }
}

fn shape_runtime() -> anyhow::Result<Store<State>> {
    let mut config = Config::new();
    config.wasm_threads(true);
    config.shared_memory(true);

    let engine = Engine::new(&config)?;
    let mut table = ResourceTable::new();
    table.set_max_capacity(4096);

    let mut wasi = WasiCtxBuilder::new();
    wasi.max_random_size(1 << 20);

    let mut store = Store::new(&engine, State { ctx: wasi.build(), table });
    store.set_hostcall_fuel(8 << 20);

    let _shared = SharedMemory::new(&engine, MemoryType::shared(1, 2))?;
    Ok(store)
}

This is not a vulnerable program. It is a map of the exact places you should look first when auditing one.

Attack Timeline

The cleanest way to understand this story is to separate the verified timeline from the rumor layer.

1. 2025-11-11: Wasmtime publishes GHSA-hc7m-r6v8-hg9q, an unsound API interaction involving WebAssembly shared linear memory. It is thread-related, but not a published privilege-escalation chain.
2. 2026-02-24: CVE-2026-27204 lands for guest-controlled resource exhaustion in Wasmtime’s WASI host interfaces. Fixes are released in 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0.
3. 2026-03-20: Wasmtime 43.0.0 adds support for WASIp3 snapshot 0.3.0-rc-2026-03-15.
4. 2026-04-09 and 2026-04-30: Wasmtime release notes show continued security churn, including sandbox-escape and memory-safety fixes across compiler and runtime surfaces. That is a reminder that this stack is actively hardening.
5. 2026-05-02: There is still no official record tying CVE-2026-6604 to a WASI Preview 3 multi-threaded privilege-escalation bug. The NVD record points elsewhere.

That timeline does not make the original claim “almost true.” It changes the story completely. The responsible read is that the ecosystem has real, recent runtime security work, but the specific CVE label in circulation is wrong.

Exploitation Walkthrough

Because there is no verified public advisory for the claimed bug, the only safe way to discuss exploitation is conceptually. Here is what a realistic chain would look like in a multi-threaded WASI runtime if such a bug did exist.

1. The attacker gets a hostile or semi-trusted WebAssembly component deployed into an embedding that enables threads, shared memory, and broad host interfaces.
2. The module uses concurrency to create timing windows around resource creation, handle transfer, or capability checks. Shared memory is useful here because it gives multiple agents a communication surface the host may incorrectly treat as stable.
3. The guest forces the host to allocate or decode large component values during callbacks, stretching bookkeeping code under pressure. That is where missing hostcall fuel, oversized lists, or unbounded resource tables become more than performance bugs.
4. If a lifecycle bug exists, a stale handle, reused slot, or insufficient revalidation step can let the guest act on a capability it should no longer have. In a capability runtime, that is the privilege-escalation moment.
5. The visible outcome is rarely “root shell.” More often it is filesystem access outside a mapped directory, use of a resource without the intended capability, or host-side action under the wrong authority.

Notice what is missing from that walkthrough: no secret JIT trick, no magic syscall bypass, and no need for a flashy native payload. Capability runtimes fail at the edges where ownership, concurrency, and validation meet. Wasmtime’s own security policy makes that explicit by treating sandbox escapes, unauthorized resource use, and execution-time denial of service as security vulnerabilities.

Hardening Guide

If you are running Wasmtime or evaluating WASIp3, the response should be concrete.

• Upgrade past known issues first. For verified WASI resource exhaustion, that means at least 24.0.6, 36.0.6, 40.0.4, 41.0.4, or 42.0.0, depending on your branch.
• Patch thread-related memory API issues. For GHSA-hc7m-r6v8-hg9q, Wasmtime lists patched versions 24.0.5, 36.0.3, 37.0.3, and 38.0.4.
• Treat WASIp3 as pre-production unless you are prepared to absorb rapid change. The docs do not present it as a stable target.
• Set explicit guest-to-host transfer budgets with Store::sethostcallfuel. Defaults are safer than nothing, but production embeddings should choose numbers intentionally.
• Cap resource growth with ResourceTable::setmaxcapacity. If a guest can create handles forever, you have already lost the first battle.
• Constrain WASI randomness and similar allocation-heavy paths with WasiCtxBuilder::maxrandomsize.
• Minimize capabilities. Every preopened directory, network permission, and inherited environment variable expands the blast radius of a logic bug.
• Disable shared memory unless you truly need it. If you do need it, audit every host path that reads or interprets guest-owned bytes.
• Sanitize forensic artifacts. Crash dumps, debug logs, and captured guest payloads can contain secrets or customer data. If your incident workflow exports evidence across teams, run it through TechBytes’ Data Masking Tool before distribution.

Architectural Lessons

The broader lesson here is not “never use WASI.” It is that the security model of WebAssembly remains strong, while the implementation complexity of modern embeddings is rising fast.

• Capability systems are only as strong as their lifecycle code. The model can be correct while the runtime still mishandles a stale resource, concurrent mutation, or host callback path.
• Preview features are security signals. When documentation says experimental and incomplete, read that as a warning about operational maturity, not just API churn.
• Concurrency multiplies audit scope. Shared memory, wake/wait behavior, and cross-thread host interaction turn “simple” validation bugs into timing-sensitive state bugs.
• Resource limits are part of the sandbox. In practice, unbounded allocation is not separate from security. It is one of the main ways a hostile guest degrades the host’s control plane.
• CVE hygiene matters. When a CVE number is wrong, teams waste hours triaging the wrong stack. Always pin claims to the official advisory, affected versions, and release notes before launching an incident response.

That is the real story behind the CVE-2026-6604 noise. The label is wrong, but the engineering pressure is real. If you are experimenting with WASIp3, especially with multi-threaded embeddings, assume the risky parts are exactly the ones where guest memory becomes host state, capabilities become long-lived resources, and concurrency turns assumptions into races.