CVE-2026-27195 is a vulnerability in the Wasmtime WebAssembly runtime, specifically in the component-model-async feature introduced as default starting with Wasmtime 39.0.0. The vulnerability stems from improper handling of exceptional conditions during asynchronous guest function calls via the [Typed]Func::call_async API. When a host embedding calls call_async on a guest export function, it receives a Future representing the asynchronous operation. If the host polls this Future once and then drops it without awaiting completion, the component instance enters a non-reenterable state because the async call never completes. Subsequent calls to call_async on the same component instance cause a trap due to the instance being non-reenterable, but before trapping, Wasmtime allocates a task and thread for the call. If the host ignores the trap and drops the Future again, the runtime panics during task disposal because the thread has not exited yet. This panic can cause a denial of service in the host application embedding Wasmtime. The issue affects Wasmtime versions >=39.0.0 and <40.0.4, and >=41.0.0 and <41.0.4. Versions 40.0.4, 41.0.4, and 42.0.0+ have patches that fix this problem. The vulnerability is classified under CWE-755 (Improper Handling of Exceptional Conditions). It requires a low privilege attacker to induce the panic by invoking asynchronous guest functions and dropping their futures prematurely. The vulnerability does not impact confidentiality or integrity but can cause availability issues due to runtime panics. Workarounds include disabling the component-model-async Cargo feature if unused or ensuring that all call_async futures are awaited to completion before reuse of the component instance or Store. The vulnerability is not known to be exploited in the wild.

The primary impact of CVE-2026-27195 is denial of service (DoS) in applications embedding Wasmtime with the component-model-async feature enabled. When exploited, the runtime panics, potentially crashing the host application or causing instability. This can disrupt services relying on WebAssembly components for execution, especially in cloud-native environments, edge computing, or serverless platforms that use Wasmtime for sandboxing untrusted code. Since the vulnerability requires the host to drop asynchronous call futures prematurely and then reuse the component instance, it may be triggered inadvertently by buggy host code or maliciously by an attacker controlling inputs to the WebAssembly environment. The vulnerability does not allow code execution, data leakage, or integrity violations but can degrade availability, impacting reliability and uptime. Organizations relying on Wasmtime for critical workloads or multi-tenant environments may face service interruptions or require emergency patching. The medium CVSS score (6.9) reflects the moderate severity due to the availability impact combined with the complexity of exploitation requiring specific host behavior.

1. Upgrade Wasmtime to version 40.0.4, 41.0.4, or later (42.0.0+) where the vulnerability is patched. 2. If the component-model-async feature is not required, disable it at compile time by disabling the Cargo feature to avoid exposure. 3. Ensure host embeddings always await the completion of call_async futures before dropping them or reusing the same component instance or Store. 4. Avoid dropping call_async futures prematurely; implement strict lifecycle management for asynchronous calls in the host embedding. 5. Conduct code reviews and static analysis on host applications embedding Wasmtime to detect improper async future handling patterns. 6. Monitor application logs for Wasmtime panics or traps indicative of this issue. 7. For environments using Tokio or other async runtimes, validate that async workflows correctly handle Wasmtime futures. 8. Consider isolating Wasmtime instances per request or user to limit impact scope if a panic occurs. 9. Engage with bytecodealliance community and maintainers for updates and best practices regarding async component usage. 10. Implement robust error handling around Wasmtime calls to gracefully recover from panics where possible.