CVE-2024-28123 Overview
CVE-2024-28123 is an out-of-bounds buffer write vulnerability affecting the Wasmi WebAssembly interpreter, a lightweight and efficient interpreter designed for constrained and embedded systems. The vulnerability occurs when a host application calls or resumes a WebAssembly (Wasm) function with more parameters than the default limit of 128, causing the interpreter to write beyond the allocated stack buffer.
Critical Impact
This out-of-bounds write vulnerability can be exploited from host-to-Wasm function calls, potentially leading to arbitrary code execution, memory corruption, or denial of service in applications using vulnerable versions of the Wasmi interpreter.
Affected Products
- wasmi-labs wasmi versions prior to 0.31.1
- Rust applications using the Wasmi crate for WebAssembly interpretation
- Embedded systems and constrained environments utilizing Wasmi for Wasm execution
Discovery Timeline
- March 21, 2024 - CVE-2024-28123 published to NVD
- June 2, 2025 - Last updated in NVD database
Technical Details for CVE-2024-28123
Vulnerability Analysis
The vulnerability exists in the Wasmi interpreter's handling of function parameters during host-to-Wasm calls. The interpreter allocates a fixed-size stack buffer capable of holding a default maximum of 128 parameters. When a host application invokes or resumes a Wasm function, it passes parameters through this buffer. However, insufficient bounds checking allows callers to supply more than 128 parameters, causing writes beyond the allocated stack space.
This flaw is classified as CWE-787 (Out-of-Bounds Write), a dangerous memory corruption vulnerability class that can lead to code execution, data corruption, or system crashes. The network attack vector indicates that applications exposing Wasmi functionality over network interfaces are particularly at risk, as remote attackers could craft malicious requests to trigger the overflow.
Root Cause
The root cause stems from inadequate validation of parameter counts during host-initiated Wasm function calls. The Wasmi interpreter assumes that host applications will respect the 128-parameter limit but does not enforce this boundary when receiving parameters from the host environment. This trust boundary violation allows parameter arrays larger than the stack allocation to be processed, resulting in memory corruption.
Attack Vector
The vulnerability is exploitable only through host-to-Wasm calls, not Wasm-to-Wasm calls within the interpreter. An attacker would need to:
- Identify an application using a vulnerable Wasmi version that accepts external input for Wasm function invocation
- Craft a malicious request that triggers a Wasm function call with more than 128 parameters
- Exploit the resulting out-of-bounds write to corrupt memory, hijack execution flow, or cause denial of service
The attack does not require authentication or user interaction, making it particularly dangerous for internet-facing applications. The vulnerability affects all three pillars of security—confidentiality, integrity, and availability—with potential for complete system compromise.
The vulnerability manifests in the parameter passing mechanism during host-to-Wasm function calls. When the host invokes call or resume methods with a parameter array exceeding 128 elements, the interpreter writes beyond the stack buffer boundaries. See the GitHub Security Advisory GHSA-75jp-vq8x-h4cq for complete technical details.
Detection Methods for CVE-2024-28123
Indicators of Compromise
- Unexpected application crashes or segmentation faults in Wasmi-based applications
- Anomalous memory access patterns or corruption in applications using WebAssembly interpretation
- Function calls with unusually high parameter counts in application logs or telemetry
- Stack corruption indicators in crash dumps from Wasmi-dependent services
Detection Strategies
- Audit dependency manifests (Cargo.toml, Cargo.lock) for Wasmi versions prior to 0.31.1
- Implement runtime monitoring for Wasm function calls with parameter counts exceeding 128
- Deploy memory protection mechanisms (ASLR, stack canaries) to detect exploitation attempts
- Use Software Composition Analysis (SCA) tools to identify vulnerable Wasmi dependencies
Monitoring Recommendations
- Enable crash reporting and memory violation logging in production environments
- Monitor for abnormal process terminations in services utilizing Wasmi
- Implement input validation at the application layer to reject excessive parameter counts before reaching the interpreter
- Review application logs for patterns indicating probing or exploitation attempts
How to Mitigate CVE-2024-28123
Immediate Actions Required
- Upgrade Wasmi to version 0.31.1 or later immediately
- Audit all applications and dependencies for vulnerable Wasmi versions
- Implement input validation to limit function parameter counts at the application boundary
- Consider temporarily disabling exposed Wasm invocation endpoints until patching is complete
Patch Information
The vulnerability was patched in Wasmi version 0.31.1. The fix implements proper bounds checking to ensure parameter counts do not exceed the stack buffer capacity during host-to-Wasm calls.
- Patched Version:0.31.1
- Patch Commit:f7b3200e9f3dc9e2cbca966cb255c228453c792f
- Release Notes:GitHub Release v0.31.1
Workarounds
- Implement application-level validation to reject function calls with more than 128 parameters before invoking Wasmi
- Deploy network-level controls to filter requests that may contain excessive parameter counts
- Isolate Wasmi-based services using sandboxing or containerization to limit blast radius of potential exploitation
- Enable memory protection features (stack canaries, ASLR) in the runtime environment to make exploitation more difficult
# Update Wasmi dependency in Cargo.toml
# Change: wasmi = "0.31.0"
# To: wasmi = "0.31.1"
# Then run cargo update to apply the fix
cargo update -p wasmi
cargo build --release
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

