How severe is GHSA-f984-pcp8-v2p7?

No CVSS score has been assigned to GHSA-f984-pcp8-v2p7 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-f984-pcp8-v2p7?

GHSA-f984-pcp8-v2p7 affects the following packages: wasmtime (crates.io), wasmtime (crates.io), wasmtime (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-f984-pcp8-v2p7?

Update wasmtime to 36.0.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f984-pcp8-v2p7 is resolved across your whole dependency graph.

How do I detect GHSA-f984-pcp8-v2p7 in my crates.io dependencies?

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.

How do I mitigate GHSA-f984-pcp8-v2p7 if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-f984-pcp8-v2p7?

O3 pinpoints whether GHSA-f984-pcp8-v2p7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-f984-pcp8-v2p7 actively exploited in the wild?

No public exploit code has been indexed for GHSA-f984-pcp8-v2p7 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 type of vulnerability is GHSA-f984-pcp8-v2p7?

GHSA-f984-pcp8-v2p7 is classified as CWE-789 (CWE-789). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-f984-pcp8-v2p7 published, and has it been updated?

GHSA-f984-pcp8-v2p7 was published on April 10, 2026 and was last updated on April 22, 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

GHSA-f984-pcp8-v2p7

GHSA-f984-pcp8-v2p7 is a CWE-789 vulnerability in wasmtime. O3 Security confirms whether GHSA-f984-pcp8-v2p7 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Wasmtime has improperly masked return value from `table.grow` with Winch compiler backend

Also known asCVE-2026-35186RUSTSEC-2026-0094

Published

Apr 10, 2026

Updated

Apr 22, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Real-World Exposure

3 pkgs affected

🦀wasmtime🦀wasmtime🦀wasmtime

Real-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

Wasmtime's Winch compiler backend contains a bug where translating the table.grow operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed.

One example can be seen when the result of table.grow is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to.

The primary consequence of this bug is that bytes in the host's address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of table.grow that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes.

Overall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime's default compiler is Cranelift, not Winch, and Wasmtime's default settings are to place guard pages before linear memory. This means that Wasmtime's default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime's otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data.

Patches

Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.

Workaround

There are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`wasmtime`	≥ 25.0.0&&< 36.0.7	36.0.7
🦀crates.io	`wasmtime`	≥ 37.0.0&&< 42.0.2	42.0.2
🦀crates.io	`wasmtime`	≥ 43.0.0&&< 43.0.1	43.0.1

Detection & mitigation playbook

Open-source dependency

Detect
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 36.0.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f984-pcp8-v2p7 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-f984-pcp8-v2p7 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-f984-pcp8-v2p7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact Wasmtime's Winch compiler backend contains a bug where translating the `table.grow` operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed. One example can be seen when the result of `table.grow` is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a

O3 Security · Impact-Aware SCA

Is GHSA-f984-pcp8-v2p7 in your dependencies?

O3 detects GHSA-f984-pcp8-v2p7 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works