How severe is GHSA-q879-9g95-56mx?

GHSA-q879-9g95-56mx 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 GHSA-q879-9g95-56mx?

GHSA-q879-9g95-56mx affects the following packages: wasmtime (crates.io), wasmtime (PyPI). Ecosystems affected: crates.io, PyPI.

How do I fix GHSA-q879-9g95-56mx?

Update wasmtime to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q879-9g95-56mx is resolved across your whole dependency graph.

How do I detect GHSA-q879-9g95-56mx 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 GHSA-q879-9g95-56mx if there is no patch (or I can't update yet)?

Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Is GHSA-q879-9g95-56mx actively exploited in the wild?

No public exploit code has been indexed for GHSA-q879-9g95-56mx 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 GHSA-q879-9g95-56mx?

GHSA-q879-9g95-56mx has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 22th 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 GHSA-q879-9g95-56mx?

GHSA-q879-9g95-56mx is classified as Use After Free (CWE-416). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-q879-9g95-56mx published, and has it been updated?

GHSA-q879-9g95-56mx was published on September 20, 2021 and was last updated on July 8, 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

Wrong type for `Linker`-define functions when used across two `Engine`sGHSA-q879-9g95-56mx

MEDIUMFix: bytecodealliance/wasmtime@b39f087

GHSA-q879-9g95-56mx is a medium-severity (CVSS 6.3) Use After Free vulnerability in wasmtime. A fix is available for wasmtime — see the affected versions and patch details below.

Also known asCVE-2021-39216 CVE-2021-39218 CVE-2021-39219 GHSA-4873-36h9-wv49 GHSA-v4cp-h94r-m7xfPYSEC-2021-320

Published

Sep 20, 2021

Updated

Jul 8, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

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

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs22th percentile — riskier than 22% of all scored CVEsHighest risk

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

How urgent is this, really

GHSA-q879-9g95-56mx by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,738 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

As a Rust library the wasmtime crate clearly marks which functions are safe and which are unsafe, guaranteeing that if consumers never use unsafe then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of Linker::func_* APIs. These APIs were previously not sound when one Engine was used to create the Linker and then a different Engine was used to create a Store and then the Linker was used to instantiate a module into that Store. Cross-Engine usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type.

Triggering this bug requires using at least two Engine values in an embedding and then additionally using two different values with a Linker (one at the creation time of the Linker and another when instantiating a module with the Linker).

It's expected that usage of more-than-one Engine in an embedding is relatively rare since an Engine is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small.

The fix implemented is to change this behavior to panic!() in Rust instead of silently allowing it. Using different Engine instances with a Linker is a programmer bug that wasmtime catches at runtime.

Patches

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

Workarounds

If you cannot upgrade Wasmtime and are using more than one Engine in your embedding it's recommended to instead use only one Engine for the entire program if possible. An Engine is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple Engines is required then code should be audited to ensure that Linker is only used with one Engine.

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`	all versions	0.30.0`cargo update -p wasmtime --precise 0.30.0`
🐍PyPI	`wasmtime`	all versions	0.30.0`pip install --upgrade 'wasmtime==0.30.0'`

Affected Products

2 products · 3 configurations

Application

wasmtimebytecodealliance

≥ 0.19.0 && < 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 GHSA-q879-9g95-56mx is resolved across your whole dependency graph.
Workarounds
Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Frequently Asked Questions

### Impact As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in W