WebAssembly smart contracts gained popularity as an alternative to traditional smart contracts, such as those written in Solidity and Vyper, due to WebAssembly’s capability as a portable and language-agnostic technology. Developers can write contracts in languages like Rust, C++, and AssemblyScript before compiling their code to WebAssembly. While WebAssembly offers performance, flexibility, and security, recent vulnerabilities in WebAssembly smart contracts call into question the extent of WebAssembly’s safety.
The Ugly: WebAssembly Smart Contract Vulnerabilities
While WebAssembly is typically seen as a memory-safe compilation target with strong sandboxed security, multiple Common Vulnerabilities and Exposures (CVEs) prove that the WebAssembly ecosystem is not immune to memory manipulation.
Several documented vulnerabilities discovered in 2023 and 2024 expose weak points involving memory management, logical flaws, and runtime environments.
In 2023, the CosmWasm vulnerability CVE-2023-33242 allowed malicious contracts to cause stack overflows by exploiting recursive calls. An attacker deployed contracts designed to repeatedly invoke functions across the contract-runtime boundary, which would crash blockchain nodes, interrupting blockchain operations and affecting network stability. In detail, an attacker would:
- Write a contract that overrides an expected function in a way that calls back into the blockchain runtime, creating a recursive loop.
- Use a function, for example, the contract’s custom allocate() function, to call into a host function, such as do_addr_validate, which calls back into allocate() again, and so on.
- Deploy the contract on a vulnerable chain that allows permissionless contract uploads. Since there are no checks to break the recursion, once the contract is executed, the recursion continues until the engine’s call stack is exhausted, causing a fatal stack overflow error.
In late 2023 and early 2024, the vulnerability CWA-2023-004 allowed attackers to upload specifically crafted WebAssembly contracts that appeared benign in size but expanded massively in memory when loaded. These “Wasm Bombs” could overwhelm node resources, causing system instability or crashes. The attacker’s contract originally consisted only of a few hundred kilobytes, but due to compiler and runtime behavior, it expanded to hundreds of megabytes in memory when the node attempted to compile or cache the contract. The node would then crash or slow down, threatening chain availability.
The CWA-2023-004 and CVE-2023-33242 exploits could have been leveraged as denial-of-service attacks without breaking WebAssembly’s sandboxed security.
With CVE-2023-51661, a flaw in the Wasmer runtime enabled contracts to bypass sandbox security restrictions, gaining unauthorized access to node file systems. This vulnerability exploited a flaw in the Wasmer runtime that failed to enforce filesystem sandboxing. Through WebAssembly file operations, an attacker running untrusted WebAssembly code on a vulnerable node could read or write the host’s file system. While this vulnerability indirectly impacts the blockchain state, sandbox escapes pose a significant security risk to nodes and the network. On the blockchain, a malicious contract could potentially use WebAssembly host import functions to attempt file access, which is typically restricted, and leverage the runtime bug so that these calls are not sandboxed, allowing the attacker to access node configuration or keys.
The Bad: Smart Contract Vulnerabilities
Common vulnerabilities that plague other smart contracts can also affect WebAssembly smart contracts. Logic bugs like missing access controls, integer overflows, reentrancy, and address normalization issues are all exploitable weak points.
For example, in 2024, the CosmWasm Bech32 bug allowed attackers to bypass checks through uppercase manipulation, demonstrating risks of inadequate input validation.
Thankfully, many blockchain platforms are aware of these logic errors and implement mitigation techniques. For example, frameworks like ink! require an explicit set_allow_reentry flag for a contract to be reentrant, which developers typically leave disabled to ensure safety.
The Good: WebAssembly Smart Contract Advantages
Even though WebAssembly encounters vulnerabilities, WebAssembly retains built-in security advantages compared to other contracts, given its sandboxing and memory management. WebAssembly enforces a strict separation between executable code and data, mitigating classic attacks such as buffer overflows or code injections.
Additionally, WebAssembly contracts can benefit from the safer language constructs of languages such as Rust. However, this adoption is a double-edged sword. Research on WebAssembly compiled from C/C++ programs confirms that in some cases, the WebAssembly can inherit vulnerabilities hidden within the source code that can become exploitable. Therefore, WebAssembly can acquire the advantages, or disadvantages, of the source code it’s compiled from.
While WebAssembly smart contracts contain security weak points, the technology is a stable and popular runtime supported on several blockchain platforms, including EOSIO, Polkadot’s Substrate, CosmWasm, and NEAR.
About the Author
Aleks Jones is a technical trainer and course author at the Linux Foundation, focusing on emerging technologies like WebAssembly and cybersecurity. As an editor for the Evil Tux blog, she evaluates technical articles, sharing insight on artificial intelligence and cybersecurity. In her leisure, she participates in capture the flag competitions.