Live › vulnerability › CVE-2026-115393
Go to dashboardSeveral Wasmtime Store APIs do not check that objects belong to the Store's Engine, so mixing objects across Engines can cause signature mismatches. An attacker who can make an embedder mix objects between Engines may cause out-of-bounds stack writes, GC heap corruption, or a panic.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only embedders of Wasmtime that create multiple Engines and pass objects from one Engine into a Store belonging to another. Applications that run a single Engine or only load Wasm modules without mixing objects are unlikely to be exposed. Users of the standalone Wasmtime CLI are not described as affected by the sources.
No product ranges from the sources yet.
wasmtime --version or check the wasmtime crate version in Cargo.lock to see whether it falls in a vulnerable range (before 24.0.12, 25.0.0 to before 36.0.13, 37.0.0 to before 46.0.2, or 47.0.0 to before 47.0.3).Instance::new, StructRefPre::new, or Tag::new that take objects created from a different Engine.24.0.12, 36.0.13, 46.0.2, or 47.0.3, matching your major release line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Wasmtime before 24.0.12, 25.0.0 before 36.0.13, 37.0.0 before 46.0.2, and 47.0.0 before 47.0.3 contains a type confusion vulnerability because several Store APIs fail to validate that objects belong to the Store's Engine. Embedders mixing objects between Engines via Instance::new, StructRefPre::new, or Tag::new can trigger trampoline signature mismatches causing out-of-bounds stack writes, GC heap corruption, or panics.
This page as .md · .json · in your agent: get_signal("CVE-2026-115393")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.