External risk intelligence

Wasmtime Stack Buffer Overflow Leads to Host Crash or Sandbox Escape

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-115384

Wasmtime is a WebAssembly runtime library used by developers to embed Wasm execution capabilities within applications. It is not an internet-facing service, gateway, or standalone appliance. Vulnerabilities in this runtime require an attacker to already have the ability to supply malicious Wasm components to an application, which is typically an internal development or application-level concern.

Buffer Overflow

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in the Wasmtime software, which is used for running WebAssembly code. This issue could allow malicious code, if supplied to the application, to disrupt operations by potentially crashing the host or escaping security boundaries. The primary concern is to confirm if this technology is used within our environment and, if so, to what extent.

A code flaw could allow unauthorized actions.
Confirm relevance and exposure of this technology.
Assess usage to understand potential security implications.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by providing a malicious WebAssembly component that contains mistyped asynchronous callback functions. When the Wasmtime runtime processes these callbacks, it may not properly validate the results, leading to a stack buffer overflow. This overflow can overwrite crucial return addresses, potentially causing the host application to crash or escape its sandbox environment.

Requires ability to supply malicious components.
Triggered by mistyped async callback results.
Risk of host crash or sandbox escape.

Live Threat

Current exploitation, exposure, and threat context

A stack buffer overflow vulnerability in Wasmtime could allow a malicious component to overwrite return addresses on the native stack, potentially leading to a crash of the host application or escape from its sandbox. This could occur when the host application processes mistyped asynchronous callback results from a specially crafted WebAssembly component.

Host application stability at risk.
Malicious guests exploit callback types.
Sandbox escape or denial of service.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Wasmtime runtime vulnerability requires immediate attention from teams managing applications that embed WebAssembly components. Initially, identify all instances of the affected Wasmtime library, confirm exposure to untrusted or malicious components, and pinpoint the owning application or development team. Subsequently, plan remediation based on the criticality of the affected applications and coordinate with vendors if necessary.

Application owners should manage remediation.
Verify WebAssembly component sources.
Plan updates during maintenance windows.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Wasmtime and why is it used?

Wasmtime is a standalone runtime for WebAssembly, designed to let developers execute untrusted code in a secure, isolated sandbox. It acts as a bridge that allows host applications—often written in languages like Rust or C—to run high-performance WebAssembly modules while keeping the main program protected from the code being executed.

What does the stack buffer overflow in CVE-2026-115384 mean?

This is a memory corruption flaw categorized as CWE-20 (Improper Input Validation). Because the runtime fails to properly verify certain async callback result types, a malicious WebAssembly component can force the system to write data past the intended memory limits. By overwriting return addresses on the stack, the attacker can hijack execution flow, potentially crashing the host or breaking out of the security sandbox.

How is this vulnerability triggered?

An attacker must supply a specifically crafted WebAssembly component containing mistyped asynchronous callback functions to the application. Standard or well-formed components that adhere to expected async callback schemas will not trigger this buffer overflow. The flaw specifically activates when the runtime attempts to process these invalid, malformed callback result types.

Is my application at risk according to Halo Surface Signal?

The risk is categorized as 'Very unlikely' because Wasmtime is a library, not an internet-facing gateway or appliance. Halo Surface Signal notes that exploitation requires an attacker to already have the ability to supply malicious WebAssembly components to your application. This vulnerability is primarily a concern for internal development workflows where untrusted components might be processed.

What should I do if I use Wasmtime?

Begin by identifying all applications in your environment that embed the affected Wasmtime library versions. Once located, verify the sources of the WebAssembly components being processed to ensure they are trusted. Coordinate with your development teams to plan an update to a secure version of the library during your next scheduled maintenance window.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.