dbcve.org
WasmtimeApplication · Bytecodealliance

CVE-2026-34988

MEDIUM · 6.3 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 →
69/100
Remediation priority · Elevated
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 28.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's implementation of its pooling allocator contains a bug where in certain configurations the contents of linear memory can be leaked from one instance to the next. The implementation of resetting the virtual memory permissions for linear memory used the wrong predicate to determine if resetting was necessary, where the compilation process used a different predicate. This divergence meant that the pooling allocator incorrectly deduced at runtime that resetting virtual memory permissions was not necessary while compile-time determine that virtual memory could be relied upon. The pooling allocator must be in use, Config::memory_guard_size configuration option must be 0, Config::memory_reservation configuration must be less than 4GiB, and pooling allocator must be configured with max_memory_size the same as the memory_reservation value in order to exploit this vulnerability. If all of these conditions are applicable then when a linear memory is reused the VM permissions of the previous iteration are not reset. This means that the compiled code, which is assuming out-of-bounds loads will segfault, will not actually segfault and can read the previous contents of linear memory if it was previously mapped. This represents a data leakage vulnerability between guest WebAssembly instances which breaks WebAssembly's semantics and additionally breaks the sandbox that Wasmtime provides. Wasmtime is not vulnerable to this issue with its default settings, nor with the default settings of the pooling allocator, but embeddings are still allowed to configure these values to cause this vulnerability. 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 pooling allocator has a memory leakage vulnerability where the predicate used to determine if resetting virtual memory permissions for linear memory differs between compile-time and runtime. When specific non-default configurations are used (memory_guard_size=0, memory_reservation<4GiB, max_memory_size=memory_reservation), the VM permissions from a previous WebAssembly instance are not reset when reusing linear memory, allowing one guest instance to read the contents of a previous instance's memory.

MitigationUpgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1. If upgrading is not immediately possible, audit configurations to ensure the pooling allocator is not using the vulnerable combination of memory_guard_size=0, memory_reservation<4GiB, and max_memory_size equal to memory_reservation.

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:>= 28.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
High
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

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

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 installed Wasmtime version
    Run 'wasmtime --version' or check the version of the Wasmtime library in use
    Affected if Version is >= 28.0.0 and < 36.0.7, OR >= 37.0.0 and < 42.0.2, OR equals 43.0.0
  2. Confirm pooling allocator is in use
    Inspect the Wasmtime configuration or runtime settings for pooling allocator enablement
    Affected if Pooling allocator is enabled for WebAssembly instance management
  3. Check memory_guard_size configuration
    Review the pooling allocator configuration for the memory_guard_size setting
    Affected if memory_guard_size is set to 0 (non-default, explicit zero value)
  4. Check memory_reservation configuration
    Review the pooling allocator configuration for the memory_reservation setting
    Affected if memory_reservation is set to less than 4 GiB (4294967296 bytes)
  5. Check max_memory_size configuration
    Review the pooling allocator configuration for max_memory_size relative to memory_reservation
    Affected if max_memory_size is configured to equal memory_reservation exactly

All three configuration conditions (memory_guard_size=0, memory_reservation<4GiB, max_memory_size=memory_reservation) must be true on an affected Wasmtime version for the vulnerability to be exploitable in your environment.

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

Upgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1. If upgrading is not immediately possible, audit configurations to ensure the pooling allocator is not using the vulnerable combination of memory_guard_size=0, memory_reservation<4GiB, and max_memory_size equal to memory_reservation.

Recommended fix High confidence

Upgrade to Wasmtime 36.0.7, 42.0.2, or 43.0.1 (or later stable releases within your major version branch)

  1. 1. Identify the current Wasmtime version in use (e.g., via cargo.toml, package-lock.json, or runtime version check)
  2. 2. Determine the appropriate upgrade path based on current version: if using 28.x-35.x, upgrade to 36.0.7 or later; if using 37.x-41.x, upgrade to 42.0.2 or later; if using 43.0.0, upgrade to 43.0.1 or later
  3. 3. Update the Wasmtime dependency in the project's dependency manifest (e.g., Cargo.toml) to the appropriate fixed version
  4. 4. Run dependency resolution and update (e.g., cargo update wasmtime)
  5. 5. Rebuild and redeploy the application
  6. 6. Verify the new version is running correctly
  7. 7. If using the pooling allocator with custom configurations, audit Config::memory_guard_size, Config::memory_reservation, and max_memory_size settings to ensure the vulnerability conditions are not met
Caveat Review Wasmtime changelogs between your current version and target version for any breaking changes in API or behavior; minor/patch upgrades typically have low risk

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

Fix this in Wasmtime Scoped from the published advisory
  • Consultation2.0 h
  • Implementation3.0 h
  • Testing2.0 h
  • Review / QA1.0 h
8.0 hours of engineering $1,420
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,272.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-34988 — 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-34988 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