Most recent entries from all

EUVD-2026-5157

fkie_cve-2024-32644

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.

GHSA-3fp5-2xwh-fxm6 — Evmos transaction execution not accounting for all state transition after interaction with precompiles

Affected: Go: github.com/evmos/evmos/v16, Go: github.com/evmos/evmos/v7, Go: github.com/evmos/evmos/v6, Go: github.com/evmos/evmos/v5, Go: github.com/tharsis/evmos, Go: github.com/tharsis/evmos/v2, Go: github.com/tharsis/evmos/v3, Go: github.com/tharsis/evmos/v4, Go: github.com/tharsis/evmos/v5

### Context

- [`stateObject`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68): represents the state of an account and is used to store its updates during a state transition. This is accomplished using two in memory Storage variables: `originStorage` and `dirtyStorage` - [`StateDB`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55): it is the general interface to retrieve accounts and holds a map of stateObjects.

### Impact

An external contributor, @iczc, discovered 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](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465). Setting the new state means we update the Cosmos SDK KVStore.

Below, are described the steps to perform the attack:

- User send a tx to a smart contract (SC) that is calling a precompile. - The SC perform a state transition of its state from A to B. - The SC call the precompile. - The SC perform a state transition of its state from B to A (revert of the previou…

Most recent entries from all

EUVD-2026-5157

fkie_cve-2024-32644

GHSA-3fp5-2xwh-fxm6 — Evmos transaction execution not accounting for all state transition after interaction with precompiles

gsd-2024-32644