How severe is CVE-2021-39219?

CVE-2021-39219 has a CVSS score of 6.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by CVE-2021-39219?

CVE-2021-39219 affects the following packages: wasmtime (crates.io), wasmtime (PyPI). Ecosystems affected: crates.io, PyPI.

How do I fix CVE-2021-39219?

Update wasmtime to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-39219 is resolved across your whole dependency graph.

How do I detect CVE-2021-39219 in my crates.io, PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2021-39219 if there is no patch (or I can't update yet)?

Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.

Is CVE-2021-39219 actively exploited in the wild?

No public exploit code has been indexed for CVE-2021-39219 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2021-39219?

CVE-2021-39219 has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 28th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2021-39219?

CVE-2021-39219 is classified as CWE-843 (CWE-843). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2021-39219 published, and has it been updated?

CVE-2021-39219 was published on September 17, 2021 and was last updated on August 7, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀

🦀 crates.io🐍 PyPI

Not in CISA KEV

MEDIUM severity

CVE-2021-39219 — wasmtime

MEDIUMFix: bytecodealliance/wasmtime@b39f087

CVE-2021-39219 is a medium-severity (CVSS 6.3) CWE-843 vulnerability in wasmtime. A fix is available for wasmtime — see the affected versions and patch details below.

Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime

Also known asCVE-2021-39216 CVE-2021-39218 GHSA-4873-36h9-wv49 GHSA-q879-9g95-56mx GHSA-v4cp-h94r-m7xfPYSEC-2021-320

Published

Sep 17, 2021

Updated

Aug 7, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Exploitation data as of Oct 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2021-39219 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,386 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

🦀wasmtime🐍wasmtime

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io, PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Impact

There was an invalid free and out-of-bounds read and write bug when running Wasm that uses externrefs in Wasmtime.

To trigger this bug, Wasmtime needs to be running Wasm that uses externrefs, the host creates non-null externrefs, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where

there are no live references at this safepoint, and
there is a safepoint with live references earlier in this frame's function.

Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack slots as externrefs that needed to be rooted for GC. At the next GC, it would be determined that nothing was referencing these bogus externrefs (because nothing could ever reference them, because they are not really externrefs) and then Wasmtime would deallocate them and run <ExternRef as Drop>::drop on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes.

Even though support for externrefs (via the reference types proposal) is enabled by default, unless you are creating non-null externrefs in your host code or explicitly triggering GCs, you cannot be affected by this bug.

We have reason to believe that the effective impact of this bug is relatively small because usage of externref is currently quite rare.

Patches

This bug has been patched and users should upgrade to Wasmtime version 0.30.0.

Additionally, we have updated our primary externref fuzz target such that it better exercises these code paths and we can have greater confidence in their correctness going forward.

Workarounds

If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal by passing false to wasmtime::Config::wasm_reference_types

References

The Wasm reference types proposal, which introduces externref

For more information

If you have any questions or comments about this advisory:

Reach out to us on the Bytecode Alliance Zulip chat
Open an issue in the bytecodealliance/wasmtime repository

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`wasmtime`	≥ 0.26.0&&< 0.30.0	0.30.0`cargo update -p wasmtime --precise 0.30.0`
🐍PyPI	`wasmtime`	≥ 0.26.0&&< 0.30.0	0.30.0`pip install --upgrade 'wasmtime==0.30.0'`

Affected Products

2 products · 3 configurations

Application

wasmtimebytecodealliance

< 0.30.0

range

fedorafedoraproject

2 versions

3435

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update wasmtime to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-39219 is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.

Frequently Asked Questions

### Impact There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where * there are no live references at this safepoint, and * there is a safepoint with live references earlier in this frame's function. Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from ea