GHSA-4873-36h9-wv49
MEDIUMOut-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
wasmtime🐍wasmtimeReal-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
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/wasmtimerepository
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | wasmtime | ≥ 0.26.0&&< 0.30.0 | 0.30.0 |
| 🐍PyPI | wasmtime | ≥ 0.26.0&&< 0.30.0 | 0.30.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update wasmtime to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4873-36h9-wv49 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4873-36h9-wv49 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4873-36h9-wv49. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4873-36h9-wv49 in your dependencies?
O3 detects GHSA-4873-36h9-wv49 across crates.io, PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.