dbcve.org
WasmtimeApplication · Bytecodealliance

CVE-2026-34987

CRITICAL · 9.9 CVSS v3.1 Published 2026-04-09
Fix available
A fix is available. Upgrade to 36.0.7 / 42.0.2 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime with its Winch (baseline) non-default compiler backend may allow properly constructed guest Wasm to access host memory outside of its linear-memory sandbox. This vulnerability requires use of the Winch compiler (-Ccompiler=winch). By default, Wasmtime uses its Cranelift backend, not Winch. With Winch, the same incorrect assumption is present in theory on both aarch64 and x86-64. The aarch64 case has an observed-working proof of concept, while the x86-64 case is theoretical and may not be reachable in practice. This Winch compiler bug can allow the Wasm guest to access memory before or after the linear-memory region, independently of whether pre- or post-guard regions are configured. The accessible range in the initial bug proof-of-concept is up to 32KiB before the start of memory, or ~4GiB after the start of memory, independently of the size of pre- or post-guard regions or the use of explicit or guard-region-based bounds checking. However, the underlying bug assumes a 32-bit memory offset stored in a 64-bit register has its upper bits cleared when it may not, and so closely related variants of the initial proof-of-concept may be able to access truly arbitrary memory in-process. This could result in a host process segmentation fault (DoS), an arbitrary data leak from the host process, or with a write, potentially an arbitrary RCE. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Wasmtime's Winch (baseline) compiler backend incorrectly assumes upper bits of a 64-bit register containing a 32-bit memory offset are cleared when they may not be. This allows properly crafted WebAssembly guests to access host memory outside the linear-memory sandbox—up to 32KiB before or ~4GiB after the memory region—bypassing bounds checking entirely. The vulnerability affects only the non-default Winch compiler (not the default Cranelift), and while a working PoC exists for aarch64, the x86-64 case may be theoretical.

MitigationIf using Winch compiler, either stop using it (revert to default Cranelift) or upgrade Wasmtime to versions 36.0.7, 42.0.2, or 43.0.1 where the fix is applied. Verify no Winch usage in production configurations.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
WasmtimeApplication
Affected:>= 25.0.0, < 36.0.7>= 37.0.0, < 42.0.2= 43.0.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the compiler backend in use
    Inspect your Wasmtime configuration or runtime flags for the compiler backend setting. Look for explicit configuration enabling 'winch' as the compiler, as opposed to the default 'cranelift'. Check CLI arguments, environment variables, or config files where the compiler is specified.
    Affected if Winch compiler backend is explicitly enabled in the runtime configuration
  2. Determine the installed Wasmtime version
    Run 'wasmtime --version' or query the library version programmatically. Compare the returned version string against the affected ranges: >= 25.0.0 and < 36.0.7; >= 37.0.0 and < 42.0.2; or exactly version 43.0.0.
    Affected if The installed version falls within any of the affected version ranges
  3. Verify WebAssembly modules with memory are executed
    Review which WebAssembly modules are being instantiated and run. Identify modules that define linear memory (check the module's memory section or look for memory instructions in the wasm binary). If only modules without memory are run, the attack surface is reduced.
    Affected if WebAssembly modules that define linear memory are being executed under the Winch compiler
  4. Check for aarch64 architecture
    Identify the target architecture where Wasmtime is running. On aarch64 systems with Winch enabled and vulnerable versions, the practical exploitability is higher as a working proof-of-concept exists.
    Affected if Running on aarch64 architecture with vulnerable Winch configuration

You are affected if your environment uses the Winch compiler backend AND runs a vulnerable Wasmtime version (25.0.0 through 36.0.6, 37.0.0 through 42.0.1, or exactly 43.0.0) while executing WebAssembly modules that define linear memory.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 36.0.7 / 42.0.2 or later
Fixed in 36.0.742.0.2
Interim mitigation

If using Winch compiler, either stop using it (revert to default Cranelift) or upgrade Wasmtime to versions 36.0.7, 42.0.2, or 43.0.1 where the fix is applied. Verify no Winch usage in production configurations.

Recommended fix High confidence

Upgrade to 36.0.7, 42.0.2, or 43.0.1 (or any later version)

  1. Upgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1 (or later)
  2. If using Winch compiler (-Ccompiler=winch), verify the upgrade completes successfully
  3. Test your WebAssembly workload to ensure functionality is preserved
  4. Alternatively, if Winch compiler is not required, switch to the default Cranelift compiler which is not affected

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Wasmtime Scoped from the published advisory
  • Consultation2.0 h
  • Implementation1.0 h
  • Testing4.0 h
  • Review / QA2.0 h
9.0 hours of engineering $1,540
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,464.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-34987 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-34987 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data