Get the Crypto Payment Security & Compliance Playbook
Back to Blog

Security Check: Do EVM-Compatible Chains Hold Up?

Code Auditing
January 4, 2024
6 min read

In November 2023, Professor Zhou Yajin, CEO of BlockSec, was invited to participate in the first Web3 Scholars Summit hosted by DRK Lab. During the conference, Professor Zhou shared BlockSec's work and achievements in detecting vulnerabilities in the EVM (Ethereum Virtual Machine). He also introduced BlockSec's automated differential fuzzing tool specifically designed to ensure the security of EVM-compatible chains. This article summarizes the content of the speech.

Introduction

According to Defillama's data statistics, there are currently 238 L1 and L2 public chains, with 144 of them being EVM-compatible. However, the question arises: Do these EVM-compatible chains have any security issues during their implementation? After conducting our research, the answer is affirmative. In response to this concern, BlockSec has launched an automated differential fuzzing security tool. Join us as we embark on a journey to explore the truth behind these EVM-compatible chains.

Vulnerabilities in Virtual Machines

Figure 1: Diagram of the Ethereum Virtual Machine (EVM) workflow
Figure 1: Diagram of the Ethereum Virtual Machine (EVM) workflow

Taking the Ethereum Virtual Machine (EVM) as an example, it adopts a stack-based architecture including Virtual ROM, Program Counter, Stack, Memory, and World State (persistent).

A virtual machine acts as the engine that interprets and executes the compiled binary code of smart contracts. The core component of many blockchain platforms is the virtual machine, with the Ethereum Virtual Machine (EVM) being particularly notable. Therefore, the virtual machine plays a key role in executing smart contracts, processing transactions, and ensuring the integrity of the blockchain.

We know that the EVM itself is also a software program written by programmers. However, how can we ensure that the EVM is free of issues? After all, bugs are possible in any code written by humans.

And once a bug appears in the EVM, it will have catastrophic consequences for the ecosystem on the blockchain. In fact, the EVM has encountered many serious vulnerabilities in the past.

For instance, in 2020, there was a vulnerability incident caused by a precompiled contract (i.e., CVE-2020-26241) [1]. The dataCopy precompiled contract in Geth (located at 0x00...04) protocol performed a shallow copy during invocation, where copying a large amount of data only copied the pointers instead of the complete data. This allowed malicious smart contracts to modify data that should not have been modified, resulting in data inconsistency when different versions of the virtual machine executed the same smart contract. Another example occurred in 2021 when certain EVM-compatible chains did not upgrade alongside Ethereum. In older versions of Geth, there was a vulnerability (CVE-2021-39137) [2] where the memory regions for input and output data in precompiled contract calls overlapped. Attackers exploited this vulnerability, resulting in a chain fork.

BlockSec's Countermeasures

How do timely discover vulnerabilities in the EVM? What are the challenges?

  1. Firstly, due to the intricate design of the virtual machine, it is challenging to find tools that can fully comprehend its operational logic. Each field of expertise requires specialization, many developers may not be able to invest a sufficient amount of effort to understand its operational logic and take effective precautions.

  2. Additionally, many L1/L2 new public chains customize the EVM virtual machine, which can potentially introduce new security issues.

Clearly, relying solely on manual audits to identify these issues on the EVM virtual machine is difficult.

Adapt and respond accordingly! In light of these challenges, BlockSec has developed an automated system to tackle these issues head-on!

Differential Fuzzing

At BlockSec, our team of experts has employed a clever approach known as differential fuzzing. By executing the same test cases on different versions of the virtual machine and comparing the output results, we can uncover potential vulnerabilities and inconsistencies. This method allows us to effectively identify subtle differences that conventional testing methods might overlook, thereby enhancing the overall security of the system.

Figure 2: Differential fuzzing Workflow
Figure 2: Differential fuzzing Workflow

Basic Working Principle:

To conduct differential fuzzing, we need to prepare identical inputs as test cases. These test cases are then fed into the differential fuzzing engine. By comparing the outputs of executing the same test cases on different versions of the virtual machine, we can identify potential issues.

Specific Implementation Steps:

The test case for differential fuzzing needs to consist of two parts: transaction metadata and pre-state. But how do we generate these transactions? We have two approaches to tackle this challenge.

  1. Reuse historical transactions: We can retrieve the historical transactions that have occurred on the blockchain and run them through different versions of the virtual machine in the differential fuzzing engine. However, relying solely on this method has its limitations. Historical transactions tend to be too "normal", whereas security testing requires uncovering corner cases—the exceptional scenarios. That's why we came up with a second approach.
  2. Coverage-guided fuzzing: We generate uncommon bytecode and historically unseen transactions from scratch, then mutate the transactions and smart contract code and input them into the virtual machine. We ensure the validity and comprehensiveness of test cases from various dimensions.

Once these transactions are generated, they are fed into the differential fuzzing engine, and the results are then compared.

The comparison of results is not merely a simple numerical comparison but also comprehensively considers data consistency in both persistent and non-persistent storage in the virtual machine. This article will no longer elaborate further.

Case Study

Figure 3: An example of the pre-compiled contract *ModExp* issue in the Aurora VM
Figure 3: An example of the pre-compiled contract ModExp issue in the Aurora VM

I'd like to share a virtual machine vulnerability case we discovered in the Aurora VM through differential fuzzing. Specifically, it relates to an issue with the ModExp precompiled smart contract.

When computing the modular exponentiation of a number x raised to the power y, we are aware that this operation requires computational resources. In a correct implementation, the gas calculation takes into account the number of iterations since modular exponentiation involves multiple iterations. However, there is a specific scenario where the gas calculation can encounter an issue: when the exponent y equals 0, indicating a zeroth-order power operation. In this case, the number of iterations becomes zero, resulting in an extremely small gas value. But in fact, the calculation still requires resources.

Conclusion

Currently, the differential fuzzing tool launched by BlockSec supports execution in the environments of various blockchain virtual machines, including rbpf, ubpf, Aurora-engine, neon-evm, Moonbeam, revm, EvmOS, fevm, and Polygon-zkevm, with continuous expansion.

With this tool, we have discovered 14 new vulnerabilities, applied for 2 CVEs: CVE-2021–46102 and CVE-2022–23066, and received over $1.3 million in bug bounties.

At present, the comprehensive EVM chain security solution provided by BlockSec (audit services + differential fuzzing tools) has been recognized and adopted by EOS and FileCoin and will contribute to the security and healthy development of their ecosystems.

Reference

[1] Shallow copy in the 0x4 precompile could lead to EVM memory corruption

[2] RETURNDATA corruption via datacopy

About BlockSec

BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaDock extension for web3 builders surfing efficiently in the crypto world.

To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.

✉️Business consulting：[email protected]

Twitter account of BlockSec: https://twitter.com/BlockSecTeam

Twitter account of Phalcon: https://twitter.com/Phalcon_xyz

Sign up for the latest updates
~$320M Lost: Liquid Network, Symbiosis Exploits | BlockSec
Security Insights

~$320M Lost: Liquid Network, Symbiosis Exploits | BlockSec

This report, covering 2026/09/07 - 2026/09/13, examines two security incidents that caused approximately $320M in losses, including the Liquid Network exploit of 2026/09/06 that the previous report did not cover. The larger was that Liquid Network exploit, where the rangeproof validation cache in Elements derived its key by hashing four fields — two of them variable in length — concatenated with nothing marking the boundaries between them, so a verdict recorded for one output was returned for another whose proof was never examined, letting the attacker create 4,000 unbacked L-BTC and peg out nearly all of them as bitcoin. On the Bitcoin route of the Symbiosis cross-chain bridge, spanning BNB Smart Chain, Ethereum and Rootstock, off-chain code that reads Bitcoin deposits took the depositor's identity from a field the depositor controls and then subtracted its fee from the deposit without checking whether the fee itself was negative, letting a 330-satoshi deposit mint `46,116,860,184.27388234 syBTC`; the pools it had to be sold through held only 11.26 syBTC, so the loss to liquidity providers and users came to an estimated 9.97 BTC (~$770K).

~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly
Security Insights

~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly

During the past week (2026/08/31 - 2026/09/06), four security incidents caused approximately $9.4M in losses across Injective, Solana, Ethereum, and Flow EVM. The largest was the Injective exploit, where an insurance fund identifier collided with a binary options market identifier and the settlement path never compared their denominations, draining about $4.8M; Aquifer on Solana lost about $2.47M because its swap path invoked an unvalidated caller-supplied Token Program, and Notional Finance V1 on Ethereum lost about $1.73M to an unchecked `uint128` cast that valued a debt at zero. Ankr FLOW on Flow EVM closed out the week with about $410K drained through a staking entry point that skipped its pause guard and minted against a stale ratio.

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing
Security Services

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing

Exchanges, payment firms, custodians, and wallet providers now lose the most money beyond the smart contract—in signing, custody, keys, people, and supply chains. Code-level audit and transaction-level monitoring each leave a gap, and traditional penetration tests may miss crypto's signing and fund semantics. This article opens our blockchain penetration testing series with the two legs of the case for institutions in scope: where the risk actually comes from, and how NYDFS, DORA, VARA, SFC, and MAS treat adversarial testing across five jurisdictions.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit