---
id: "CVE-2026-54912"
kind: "vulnerability"
aliases: ["CVE-2026-54912"]
title: "WAMR: crafted Wasm module corrupts heap and crashes the host process"
severity: "high"
cvss: 8.8
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded-runtime", "runtime", "wamr", "webassembly"]
not_affected_if: ["fast-interp-disabled", "trusted-modules-only"]
published_at: "2026-11-05T18:17:08+00:00"
first_seen_at: "2026-11-05T18:40:09+00:00"
updated_at: "2026-11-05T18:40:20+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54912", "first_seen_at": "2026-11-05T18:40:09+00:00"}]
exploit_sources: []
---

# WAMR: crafted Wasm module corrupts heap and crashes the host process

WebAssembly Micro Runtime (WAMR) before 2.4.5 has a heap buffer overflow in its fast interpreter loader, triggered by a crafted module during loading. An attacker who supplies a malicious Wasm module can corrupt host heap metadata and deterministically crash the process, causing denial of service; further impact depends on the host application's heap layout.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build sets `WAMR_BUILD_FAST_INTERP=1`, which the sources say is required for the flaw.
- Check the WAMR version in use against `2.4.5`.

## Fix

- WAMR: move to `2.4.5` or later.

## Timeline

- 2026-11-05T18:40:09+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-54912

## Documents

- [advisory] Vendor advisory: github.com https://github.com/wasm-micro-runtime/wasm-micro-runtime/security/advisories/GHSA-jjv3-x3jf-cg49
- [fix] Patch: github.com https://github.com/wasm-micro-runtime/wasm-micro-runtime/commit/b1353b5e8983047ff68829c99abf1355d5f389cf
- [fix] Release notes: github.com https://github.com/wasm-micro-runtime/wasm-micro-runtime/releases/tag/WAMR-2.4.5

## From the sources

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, the two-pass fast interpreter loader in core/iwasm/interpreter/wasm_loader.c can make inconsistent constant-table decisions between the sizing pass and the emitting pass. After duplicate constants inflate the first pass beyond the constant-slot limit, wasm_loader_get_const_offset emits later constants inline, but the between-pass sort and deduplication reduces the table so the second pass can choose table references and cause reserve_block_ret to emit additional copy operands that were not included in code_compiled_peak_size. A crafted module can therefore make the second pass write partially attacker-controlled compiled-code data beyond the heap buffer allocated from the first pass's size calculation during wasm_runtime_load, before guest code executes. This can corrupt host heap metadata and deterministically crash the process, causing denial of service; further consequences depend on the host application's heap layout. Builds using WAMR_BUILD_FAST_INTERP=1 are affected; disabling the fast interpreter avoids the vulnerable loader. This issue is fixed in version 2.4.5.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_