Skip to main content
VulnerabilityPublished

CVE-2026-27195: bytecodealliance wasmtime · Improper Handling of Exceptional Conditions

Affects bytecodealliance wasmtimeSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 6.9 Medium : upgrade to 41.0.4 or 40.0.4 when convenient.

Data as of 29 Oct 2026, 19:04 UTC

CVSS 4.0 base score
6.9Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 35% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 41.0.4, 40.0.4
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade wasmtime and github/bytecodealliance/wasmtime to 41.0.4 or 40.0.4.

Affected software

ProductAffectedFixed in
bytecodealliancewasmtimeAffected
  • >=41.0.0 <41.0.4
Fixed in
  • 41.0.4
bytecodealliancewasmtimeAffected
  • >=39.0.0 <40.0.4
Fixed in
  • 40.0.4
crates.iogithub/bytecodealliance/wasmtimepkg:cargo/github/bytecodealliance/wasmtimeOther threatsAffected
  • <40.0.4
  • >=40.0.0 <40.0.4
  • >=41.0.0 <41.0.4
Fixed in
  • 40.0.4
  • 41.0.4

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Upgrade Wasmtime to version 40.0.4, 41.0.4, or later where the vulnerability is patched.
  2. If the component-model-async feature is not used, disable it at compile time via Cargo features to avoid exposure.
  3. Ensure that all asynchronous calls made via [Typed]Func::call_async are awaited to completion before dropping their Futures.
  4. Avoid reusing the same Store instance after dropping a not-yet-resolved call_async Future to prevent entering a non-reenterable state.
  5. Implement robust error handling around async calls to detect and recover from panics or traps gracefully.
  6. Conduct code reviews and static analysis focusing on async call patterns in Wasmtime embeddings.
  7. Monitor application logs for unexpected panics or crashes related to async WebAssembly calls.
  8. Educate developers on proper async usage patterns with Wasmtime to prevent misuse.
  9. Consider isolating Wasmtime components in separate processes or containers to limit impact of crashes.
  10. Stay updated with bytecodealliance advisories for any further patches or mitigations.

Description

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.

References

Community reviews

Loading reviews…