CVE-2022-39392 is a medium-severity (CVSS 5.9) Buffer Overflow vulnerability in wasmtime. A fix is available for wasmtime — see the affected versions and patch details below.
Wasmtime vulnerable to out of bounds read/write with zero-memory-pages configuration
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2022-39392.
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.
How urgent is this, really
CVE-2022-39392 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
wasmtime🦀wasmtimeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Impact
There is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator.
This bug can only be triggered by setting InstanceLimits::memory_pages to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime, hence the low severity of this bug despite the critical consequences.
Patches
This bug has been patched and users should upgrade to Wasmtime 2.0.2.
Workarounds
One way to mitigate this issue is to disable usage of the pooling allocator. Note that the pooling allocator is not enabled by default.
This bug can also only be worked around by increasing the memory_pages allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the Store::limiter method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default memory_pages value is greater than zero.
This bug is not applicable with the default settings of the wasmtime crate.
References
Config::allocation_strategy- configuration required to enable the pooling allocator.InstanceLimits::memory_pages- configuration field that, when zero, exhibits this bug.Store::limiter- means of limiting memory without usingmemory_pages- Mailing list announcement
- Patch for the
release-2.0.0branch
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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | wasmtime | ≥ 2.0.0&&< 2.0.2 | 2.0.2cargo update -p wasmtime --precise 2.0.2 |
| 🦀crates.io | wasmtime | all versions | 1.0.2cargo update -p wasmtime --precise 1.0.2 |
Detection & mitigation playbook
Open-source dependencyDetect
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 2.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2022-39392 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2022-39392 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2022-39392. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2022-39392 in your dependencies?
O3 Security finds CVE-2022-39392 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.