Skip to content
CVE-2026-115889 Elastic Security · Elastic

Detect Wasmtime Cranelift Bit-Packing Silent Overflow Miscompilation (CVE-2026-115889) in Elastic Security

Detects presence and execution of vulnerable Wasmtime runtime versions affected by CVE-2026-115889, a critical (CVSS 9.9) bit-packing defect in the Cranelift compiler that causes silent integer overflow (CWE-197) and type-confusion miscompilation (CWE-843). Affected versions are Wasmtime < 36.0.19 and >= 37.0.0, < 43.0.0. A maliciously crafted WebAssembly module can trigger miscompilation that violates Wasm sandboxing guarantees, enabling memory corruption and potential sandbox escape. A public PoC exists via GHSA-897f-g5gm-fmxm. This detection surfaces vulnerable binaries, crate dependencies, and runtime process behavior indicative of guest-triggered miscompilation (crashes, SIGSEGV/SIGILL in JIT-compiled regions, and unexpected host access from Wasm workloads).

MITRE ATT&CK

Tactic
Execution Privilege Escalation

Elastic Detection Query

Elastic Security (Elastic)
eql 
process where event.type == "start" and
  (process.name : ("wasmtime", "wasmtime.exe") or process.command_line : "*wasmtime*") and
  not process.version : ("36.0.19", "36.0.2?", "43.*", "44.*", "45.*", "46.*")
critical severity medium confidence

Elastic EQL rule matching Wasmtime process starts while excluding known-fixed version strings (36.0.19+ patch line and 43.x+). Matches warrant version confirmation against the affected ranges.

Data Sources

Elastic DefendWinlogbeat/Auditbeat process events

Required Tables

logs-endpoint.events.process-*

False Positives & Tuning

  • Fixed versions whose version string does not populate process.version and therefore are not excluded
  • Embedded Wasmtime where process.name reflects the host binary rather than wasmtime
  • Intentional execution of legacy Wasmtime in a dev environment

Other platforms for CVE-2026-115889

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 Detect vulnerable Wasmtime version via CLI

    Expected signal: Process launch event for 'wasmtime' with version string 42.0.0 in the command line / version metadata.

  2. Test 2 Execute a trivial WebAssembly module through vulnerable Wasmtime

    Expected signal: Wasmtime process launch with a .wat/.wasm argument on the command line, indicating guest module ingestion.

  3. Test 3 Inventory embedded Wasmtime crate version from Cargo.lock

    Expected signal: File read / dependency-scan event exposing wasmtime crate version 40.0.1.

Last updated: 2026-10-24 Research depth: standard
References (9)

Response Playbook

Triage

  1. Confirm the exact Wasmtime version in scope: for standalone CLI run `wasmtime --version`; for embedded use inspect the application's `Cargo.lock` for the `wasmtime` crate version. Compare against affected ranges < 36.0.19 and >= 37.0.0, < 43.0.0.
  2. Determine whether the host accepts untrusted/attacker-supplied WebAssembly modules (multi-tenant serverless, plugin systems, edge compute). Hosts that only run first-party trusted Wasm are materially lower risk.
  3. Review process telemetry for the flagged host for abnormal Wasmtime terminations — SIGSEGV, SIGILL, SIGABRT, or Windows access-violation (0xC0000005) crashes — correlated with new or anomalous guest module loads.
  4. Check whether Cranelift JIT compilation is in use (default) versus the Winch baseline compiler or a precompiled AOT (.cwasm) artifact, since the defect is in the Cranelift optimizing path.

Containment

  1. Upgrade Wasmtime to a fixed release: 36.0.19 for the 36.x line, or 43.0.0+ for 37.x–42.x deployments. Rebuild and redeploy any application embedding the crate.
  2. Where immediate upgrade is not possible, restrict the runtime to execute only trusted, signed WebAssembly modules and disable ingestion of untrusted guest Wasm.
  3. For multi-tenant hosts, isolate or suspend tenants supplying unverified modules and apply additional OS-level sandboxing (seccomp, separate process/user, memory limits) around the Wasmtime process.

Evidence Collection

  1. Capture the suspect WebAssembly module(s), the Wasmtime version, launch command line, and any generated .cwasm cache artifacts for offline analysis.
  2. Collect crash evidence: core dumps, Windows error reports / WER dumps, and kernel/EDR records of the faulting process and faulting address within JIT-compiled memory regions.
  3. Preserve `Cargo.lock`, build manifests, and container image digests to establish the precise deployed version and provenance.

Escalation Criteria

  • !Escalate to incident response if a vulnerable host runs untrusted Wasm AND shows crashes or anomalous host-resource access (unexpected file/network syscalls) coincident with guest module execution — treat as potential sandbox escape.
  • !Escalate if the captured module reproduces miscompilation/memory corruption in an isolated reproduction environment, or matches the public PoC from GHSA-897f-g5gm-fmxm.
  • !Escalate to vendor/platform owners if the vulnerable runtime is embedded in a widely deployed product requiring coordinated patch rollout.

Investigation Guide

Forensic Artifacts

  • >Wasmtime version metadata (binary version info / Cargo.lock entry)
  • >Cached compiled module artifacts (.cwasm files) in the Wasmtime module cache directory
  • >Process crash dumps / core files showing faults in JIT-compiled memory regions
  • >The attacker-supplied .wasm/.wat module and its ingestion logs

Tuning Guidance

Baseline the set of hosts legitimately running Wasmtime and the versions they carry; once an inventory is established, suppress known-patched (36.0.19+, 43.0.0+) hosts and alert only on vulnerable-range matches or on new/unexpected Wasmtime installations. If the runtime is embedded and does not expose a parseable version string, pivot to software-inventory/SBOM (Cargo.lock) scanning rather than process-version parsing to reduce null-version noise. Prioritize alerts from hosts that ingest untrusted WebAssembly.

Hunting Queries

Hunts for Wasmtime executions temporally correlated with process crash events (SIGSEGV/SIGILL/access violations), a behavioral indicator of triggered miscompilation or attempted sandbox escape.

Hunting — KQL
kql 
DeviceProcessEvents | where FileName in~ ("wasmtime","wasmtime.exe") or ProcessCommandLine has "wasmtime" | join kind=inner (DeviceEvents | where ActionType in ("ProcessCrash","AppCrash")) on DeviceId | project Timestamp, DeviceName, ProcessCommandLine, ActionType
Hunting — SPL
spl 
index=endpoint (process="*wasmtime*") OR (sourcetype=*crash* "wasmtime") | transaction host maxspan=5m | search (SIGSEGV OR SIGILL OR 0xC0000005 OR access_violation) | table _time host process

Atomic Red Team Tests

Test 1 Detect vulnerable Wasmtime version via CLI
linux

Installs and runs a Wasmtime version within the vulnerable range and queries its version, generating process telemetry that the detection should flag.

Command

bash 
curl -sSfL https://github.com/bytecodealliance/wasmtime/releases/download/v42.0.0/wasmtime-v42.0.0-x86_64-linux.tar.xz -o /tmp/wt.tar.xz && tar -xf /tmp/wt.tar.xz -C /tmp && /tmp/wasmtime-v42.0.0-x86_64-linux/wasmtime --version

Cleanup

bash 
rm -rf /tmp/wt.tar.xz /tmp/wasmtime-v42.0.0-x86_64-linux

Expected Telemetry

Process launch event for 'wasmtime' with version string 42.0.0 in the command line / version metadata.

Expected Detection

Detection flags the execution as is_vulnerable=true because 42.0.0 falls in the >= 37.0.0, < 43.0.0 range.

Test 2 Execute a trivial WebAssembly module through vulnerable Wasmtime
linux

Runs a benign .wat module through a vulnerable Wasmtime build to simulate guest module execution that could carry a malicious payload in a real attack.

Command

bash 
printf '(module (func (export \"main\")))' > /tmp/t.wat && /tmp/wasmtime-v42.0.0-x86_64-linux/wasmtime run --invoke main /tmp/t.wat

Cleanup

bash 
rm -f /tmp/t.wat

Expected Telemetry

Wasmtime process launch with a .wat/.wasm argument on the command line, indicating guest module ingestion.

Expected Detection

Detection correlates vulnerable Wasmtime execution with module ingestion on the command line.

Test 3 Inventory embedded Wasmtime crate version from Cargo.lock
linux

Scans a Rust project's Cargo.lock for a vulnerable wasmtime crate dependency, modeling SBOM-based detection of embedded vulnerable runtimes.

Command

bash 
printf '[[package]]\nname = \"wasmtime\"\nversion = \"40.0.1\"\n' > /tmp/Cargo.lock && grep -A1 'name = "wasmtime"' /tmp/Cargo.lock

Cleanup

bash 
rm -f /tmp/Cargo.lock

Expected Telemetry

File read / dependency-scan event exposing wasmtime crate version 40.0.1.

Expected Detection

SBOM/dependency scanning flags wasmtime 40.0.1 as within the vulnerable >= 37.0.0, < 43.0.0 range.

Related Detections

Tactic Hubs

TA0002 Execution TA0004 Privilege Escalation ATT&CK Matrix

Related Techniques

T1211 Exploitation for Defense Evasion T1203 Exploitation for Client Execution T1068 Exploitation for Privilege Escalation

Same Tactic: Execution

Popular Detections