Wasmtime CVE-2026-121439

Exploitation requires that the host embeds Wasmtime and runs untrusted/attacker-supplied WebAssembly guests through the wasi-http p3 (preview 3) HTTP implementation; the guest must be able to produce a response that splices an existing body into a new response while supplying a content-length header, which Wasmtime versions >=46.0.0 <48.0.7 and >=49.0.0 <49.0.4 fail to validate. Limiting factors: the attacker must already be an executing guest within the runtime (this is Wasmtime's untrusted-guest boundary, not an anonymous external request), the deployment must use the experimental wasi-http p3 API specifically, and realized impact depends on a downstream HTTP consumer (proxy, cache, or client) that mishandles the inconsistent content-length. Impact is limited to HTTP message-integrity (response splitting/injection); there is no direct confidentiality or availability loss on the Wasmtime host.

This is a genuine but moderate-priority issue rather than an emergency. The CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes severity as network-reachable, low-complexity and requiring no privileges, but the only impact metric set is VI:L - integrity-low, with no confidentiality (VC:N) or availability (VA:N) effect - which correctly caps the score at 6.9 (medium). The vuln.today decision label is 'this_month,' consistent with a real-but-not-urgent fix. Critically, the CVSS PR:N must be read against the actual threat model: the attacker is a malicious WebAssembly guest, so 'no privileges' means the attack needs no host credentials, NOT that any anonymous internet user can trigger it - exploitation presupposes a deployment that executes untrusted wasip3 guests through the experimental wasi-http p3 implementation, which meaningfully narrows real-world exposure. No EPSS score, no CISA KEV listing, and no confirmed proof-of-concept exploit code were provided; the two references are the Bytecode Alliance GHSA advisory and a VulnCheck advisory, both vendor/analyst advisories rather than working exploit code. There are no conflicting signals here - all sources agree on a guest-to-output integrity flaw - but the absence of EPSS/KEV data means widespread active exploitation cannot be assessed and should not be assumed.

An operator runs untrusted third-party WebAssembly components on Wasmtime using the wasi-http p3 interface (for example a serverless or edge-compute platform). A malicious guest splices an existing response body into a new response while setting a content-length header that does not match the actual body, and Wasmtime forwards it without validation. A downstream HTTP client, proxy, or cache then desynchronizes on the message framing, enabling response splitting/injection against other consumers. No public exploit code is identified at time of analysis.