CVE-2024-32644 in Evmos
Summary
by MITRE • 04/19/2024
Evmos is a scalable, high-throughput Proof-of-Stake EVM blockchain that is fully compatible and interoperable with Ethereum. Prior to 17.0.0, there is a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, **if and only if** it is different than the `originStorage`, we set the new state. Setting the new state means we update the Cosmos SDK KVStore. If a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is **critical** since this could lead to drain of funds through creative SC interactions. The issue has been patched in versions >=V17.0.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/06/2025
The vulnerability identified as CVE-2024-32644 affects the Evmos blockchain platform, a Proof-of-Stake EVM blockchain designed for scalability and Ethereum compatibility. This critical flaw exists in versions prior to 17.0.0 and stems from a fundamental inconsistency between the Cosmos SDK state and Ethereum Virtual Machine storage states during transaction execution. The issue manifests through improper state synchronization mechanisms that create opportunities for malicious actors to exploit temporal inconsistencies in storage updates.
The technical root cause involves the `stateDB.Commit()` method which handles synchronization between Cosmos SDK KVStore and EVM storage states. During transaction processing, the system iterates through `dirtyStorage` entries and only updates the Cosmos SDK KVStore when `dirtyStorage` differs from `originStorage`. However, this approach creates a race condition scenario where contract storage states can be modified during transaction execution while maintaining the appearance of atomicity. Specifically, when a storage slot remains unchanged from the original state but undergoes modification during transaction execution, and subsequently calls an external contract that modifies the same storage slot, the system fails to properly account for these intermediate changes.
This vulnerability represents a classic example of a race condition and state inconsistency issue that falls under CWE-362, which addresses race conditions in concurrent systems. The flaw allows for arbitrary token minting through manipulation of storage state during transaction execution, creating a scenario where the system's atomicity guarantees are compromised. Attackers can exploit this by crafting smart contracts that manipulate storage values during execution flow, potentially causing the system to commit incorrect state updates that result in unintended token creation.
The operational impact of this vulnerability is severe and directly threatens the financial integrity of the Evmos network. An attacker could potentially drain funds through sophisticated smart contract interactions that exploit the inconsistent state management. The vulnerability's critical severity classification stems from its ability to enable unauthorized token generation, which could lead to monetary losses for network participants and undermine confidence in the platform's security. The exploit requires careful crafting of transaction sequences that take advantage of the temporal gaps between state updates, making it particularly dangerous as it can be executed without requiring privileged access or network-level attacks.
Mitigation strategies should focus on upgrading to version 17.0.0 or later, which implements proper state synchronization mechanisms. The fix addresses the underlying race condition by ensuring that all storage modifications are properly accounted for during transaction execution and commitment phases. Organizations should also implement comprehensive testing procedures to verify that smart contracts behave correctly under various state modification scenarios. Additionally, network operators should monitor for any suspicious transaction patterns that might indicate exploitation attempts. The vulnerability highlights the importance of proper state management in blockchain systems and demonstrates the critical need for atomicity guarantees in distributed ledger environments. This issue aligns with ATT&CK technique T1499.004, which covers the exploitation of vulnerabilities in blockchain systems to manipulate financial assets, and underscores the necessity of robust state consistency mechanisms in distributed systems.