Use after free passing externrefs to Wasm in Wasmtime

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS 4.0

5.8 · CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N · score source

EPSS

• CVE-2021-39216: 0.31% estimated exploitation activity in the next 30 days; percentile 23.59 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.
• CVE-2021-39218: 0.30% estimated exploitation activity in the next 30 days; percentile 22.84 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.
• CVE-2021-39219: 0.36% estimated exploitation activity in the next 30 days; percentile 29.96 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

Impact There was a use-after-free bug when passing `externref`s from the host to guest Wasm content. To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by * passing multiple `externref`s as arguments from host code to a Wasm function, * or returning multiple `externref`s to Wasm from a multi-value return function defined in the host. If you do not have host code that matches one of these shapes, then you are not impacted. If Wasmtime's `VMExternRefActivationsTable` became filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. However the first `externref` is not rooted until we pass control to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or…

Published by the source

20 Sep 2021, 19:54 UTC

Last modified by the source

8 Jul 2026, 06:29 UTC

Source last checked

25 Oct 2026, 01:37 UTC

1. Revision 4 · amended · 25 Oct 2026

   Reviewed OSV alias/range/CVSS4 correction; package source scopes and original publication preserved. No customer finding resolved.

2. Revision 3 · amended · 24 Oct 2026

   Amended from osv record GHSA-v4cp-h94r-m7xf

3. Revision 2 · amended · 24 Oct 2026

   Amended from osv record GHSA-q879-9g95-56mx

4. Revision 1 · created · 24 Oct 2026

   Published from osv record GHSA-4873-36h9-wv49

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2021-39216

Advisory: Use after free passing `externref`s to Wasm in Wasmtime
IDs: CVE-2021-39216, GHSA-4873-36h9-wv49
Record: https://patchnext.com/advisories/cve-2021-39216 (revision 4, source checked 25 Oct 2026, 01:37 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 5.8)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: wasmtime 0.30.0; wasmtime 0.30.0. A vendor fix does not mean a deployment is fixed.

## Affected components
- PyPI wasmtime: affected < 0.30.0; fixed in 0.30.0
- crates.io wasmtime: affected < 0.30.0; fixed in 0.30.0

## Suggested inspection (read-only)
- `python -m pip show wasmtime`: prints the installed version. Run with the environment that serves production active.
- crates.io wasmtime: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on wasmtime.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-4873-36h9-wv49 (OSV record GHSA-4873-36h9-wv49 lists affected ranges: crates.io wasmtime >=0.26.0 =0.26.0 <0.30.0 (fixed))
- Verified: https://osv.dev/vulnerability/GHSA-q879-9g95-56mx (OSV record GHSA-q879-9g95-56mx lists affected ranges: crates.io wasmtime >=0 =0 <0.30.0 (fixed))
- Verified: https://osv.dev/vulnerability/GHSA-v4cp-h94r-m7xf (OSV record GHSA-v4cp-h94r-m7xf lists affected ranges: crates.io wasmtime >=0 =0 <0.30.0 (fixed))

Commands are suggestions: review each one before running it.