CVE-2026-27195
Bytecodealliance Wasmtime 39.0.0 – 40.0.4
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-27195 is a medium-severity Improper Handling of Exceptional Conditions (CWE-755) vulnerability in Bytecodealliance Wasmtime. Its CVSS base score is 6.9 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Client Execution (T1203); ranked at the 29th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-24 (Fail in Known State) and SI-17 (Fail-safe Procedures) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27195 is a denial-of-service vulnerability in Wasmtime, a runtime for WebAssembly, affecting versions starting from 39.0.0 where the `component-model-async` feature is enabled by default. The issue stems from a bug in the new implementation of `[Typed]Func::call_async`, which allows calling async-typed guest export functions. Under specific conditions, this leads to a runtime panic: the host embedding calls `call_async` on a component-exported function and polls the returned Future once; the component yields control (e.g., via a host function wrapped with `LinkerInstance::func_wrap_async` or an epoch interruption); the host drops the Future without resolution; a subsequent `call_async` on the same instance traps after allocating resources; and dropping the second Future triggers a panic during task disposal.
The vulnerability can be exploited by remote attackers with no privileges over hosts embedding Wasmtime in network-accessible services running affected versions with `component-model-async` enabled. A malicious WebAssembly component can induce the panic sequence if the host implementation prematurely drops an unresolved `call_async` Future and reattempts the call on the same instance, resulting in a crash of the Wasmtime runtime and denial of service (CVSS 3.1 score of 7.5, with high availability impact and no confidentiality or integrity effects; CWE-755).
Patches are available in Wasmtime 40.0.4 and 41.0.4, while versions 42.0.0 and later are unaffected. Embeddings not using component-model-async features can disable that Cargo feature as a workaround. Additional mitigations include ensuring all `call_async` Futures are awaited to completion or avoiding reuse of the `Store` after dropping an unresolved Future, as detailed in the Wasmtime release notes and fix commits.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8567
Vulnerability Data
Wasmtime is a runtime for WebAssembly. Starting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions. However, that implementation had a…
more
bug leading to a panic under certain circumstances: First, the host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once. Second, the component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption. Third, the host embedding drops the `Future` after polling it once. This leaves the component instance in a non-reenterable state since the call never had a chance to complete. Fourth, the host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`. Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call. Fifth, the host embedding ignores the trap and drops the `Future`. This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited. When a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected. Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected. If an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 1 hardening rule · 1 OS baseline
—
Mitigating Controls (NIST 800-53 r5) AI
Requires the system to fail to a known safe state on specified failures, limiting the impact of unhandled exceptional conditions.
Mandates explicit fail-safe procedures triggered by indicated failures, structurally preventing unhandled or mishandled exceptional conditions.
Requires generation of appropriate error messages on exceptional conditions, directly enforcing correct handling rather than silent or incorrect behavior.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices explicitly require proper exception and error handling during design and coding.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance verifies correct handling of exceptional conditions.
Documented operating procedures may specify exception handling but do not guarantee implementation.
Logging captures unhandled exceptions, aiding detection but not preventing the weakness.
Monitoring can surface unhandled exceptions but does not enforce proper handling.
Secure SDLC mandates exception-handling requirements and testing that directly prevent improper handling of exceptional conditions.
Application security requirements explicitly include handling of error and exceptional conditions.