CVE-2026-27195
📋 TL;DR
A bug in Wasmtime's async component model implementation causes a panic when call_async futures are dropped before completion and then called again on the same component instance. This affects Wasmtime users who use the component-model-async feature with affected versions. The vulnerability leads to denial of service through application crashes.
💻 Affected Systems
- Wasmtime
📦 What is this software?
Wasmtime by Bytecodealliance
Wasmtime by Bytecodealliance
⚠️ Risk & Real-World Impact
Worst Case
Application crashes and becomes unavailable, causing denial of service for all users of the affected service.
Likely Case
Intermittent application crashes when async component functions are improperly handled, leading to service disruptions.
If Mitigated
No impact if proper async handling practices are followed or if the component-model-async feature is disabled.
🎯 Exploit Status
Exploitation requires specific async programming patterns and access to call async component functions. Not easily weaponized for remote code execution.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 40.0.4, 41.0.4, or 42.0.0+
Vendor Advisory: https://github.com/bytecodealliance/wasmtime/releases/tag/v40.0.4
Restart Required: Yes
Instructions:
1. Update Wasmtime to version 40.0.4, 41.0.4, or 42.0.0+. 2. Rebuild and redeploy applications using Wasmtime. 3. Restart affected services.
🔧 Temporary Workarounds
Disable component-model-async feature
allDisable the vulnerable feature if not needed
Add 'default-features = false' to Wasmtime dependency in Cargo.toml
Remove 'component-model-async' from features list
Proper async future handling
allEnsure all call_async futures are awaited to completion
Modify code to await all async function calls: let result = func.call_async(...).await;
🧯 If You Can't Patch
- Disable component-model-async feature in Cargo.toml configuration
- Implement strict async handling patterns: never drop unresolved call_async futures
🔍 How to Verify
Check if Vulnerable:
Check Wasmtime version and if component-model-async feature is enabled: cargo tree | grep wasmtimeCheck Version:
wasmtime --version or check Cargo.lock for wasmtime versionVerify Fix Applied:
Verify Wasmtime version is 40.0.4, 41.0.4, or 42.0.0+: wasmtime --version📡 Detection & Monitoring
Log Indicators:
- Panic messages containing 'thread panicked' or 'component instance cannot be entered'
- Application crash logs with Wasmtime stack traces
Network Indicators:
- Sudden service unavailability
- Increased error rates in async WebAssembly operations
SIEM Query:
source="application.logs" AND ("panic" OR "thread panicked") AND "wasmtime"🔗 References
- https://bytecodealliance.zulipchat.com/#narrow/channel/206238-general/topic/.E2.9C.94.20Panic.20in.20Wasmtime.2041.2E0.2E3.20.28runtime.2Fconcurrent.2Fcomponent.29/with/574438798
- https://github.com/bytecodealliance/wasmtime/commit/9e51c0d9a240a9613d279c061f82286bd11383fd
- https://github.com/bytecodealliance/wasmtime/commit/d86b00736b9ece60b3c81e52f7a7e4cdd9f7d895
- https://github.com/bytecodealliance/wasmtime/releases/tag/v40.0.4
- https://github.com/bytecodealliance/wasmtime/releases/tag/v41.0.4
- https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xjhv-v822-pf94
