Vulnerability Database

358,842

Total vulnerabilities in the database

CVE-2026-27195 — bytecodealliance / wasmtime

Improper Handling of Exceptional Conditions

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 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.

CVSS v3:

  • Severity: High
  • Score: 7.5
  • AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWEs:

Software From Fixed in
bytecodealliance / wasmtime 39.0.0 40.0.4
bytecodealliance / wasmtime 41.0.0 41.0.4
Rust icon wasmtime 39.0.0 40.0.4
Rust icon wasmtime 41.0.0 41.0.4

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.