{"id":"CVE-2024-32644","aliases":["GHSA-3fp5-2xwh-fxm6","GO-2024-2715"],"title":"Evmos transaction execution not accounting for all state transition after interaction with precompiles","summary":"Evmos transaction execution not accounting for all state transition after interaction with precompiles","severity":"critical","cvss":9.1,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","vendor":"evmos","product":"github.com/evmos/evmos/v16","ecosystem":"go","affected":["github.com/evmos/evmos/v16 < 17.0.0","github.com/evmos/evmos/v7 <= 7.0.0","github.com/evmos/evmos/v6 <= 6.0.4","github.com/evmos/evmos/v5 <= 5.0.0","github.com/tharsis/evmos <= 1.1.3","github.com/tharsis/evmos/v2 <= 2.0.2","github.com/tharsis/evmos/v3 <= 3.0.3","github.com/tharsis/evmos/v4 <= 4.0.2","github.com/tharsis/evmos/v5 <= 5.0.1"],"patched":["github.com/evmos/evmos/v16 17.0.0"],"published":"2024-04-10","updated":"2026-09-10","sourceUpdated":"2026-09-10T03:50:10.906001718Z","source":"OSV","sourceUrl":"https://osv.dev/vulnerability/GHSA-3fp5-2xwh-fxm6","references":[{"url":"https://github.com/evmos/evmos/security/advisories/GHSA-3fp5-2xwh-fxm6"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-32644"},{"url":"https://github.com/evmos/evmos/commit/08982b5ee726b97bc50eaf58d1914829648b6a5f"},{"url":"https://github.com/evmos/evmos"},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68"},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55"},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465"}],"tags":["osv","go"],"epss":0.00943,"epssPercentile":0.58972,"ingestedAt":"2026-09-12T03:13:01.749Z","slug":"CVE-2024-32644","body":"## Overview\n\n### Context\n\n- [`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`\n- [`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.\n\n### Impact\n\nAn 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. \n\nBelow, are described the steps to perform the attack:\n\n- User send a tx to a smart contract (SC) that is calling a precompile. \n- The SC perform a state transition of its state from A to B.\n- The SC call the precompile.\n- The SC perform a state transition of its state from B to A (revert of the previous).\n- Once the transaction is executed, and the final **Commit** is performed, the state A will not be committed to the store because A is the same as `originStorage`. \n\nIf the tx is executed correctly, this is what happens at the store level:\n\n- Initial state A is loaded from the KVStore and the dirtyStorage is set to B.\n- Before running the precompile, the `dirtyStorage` is committed to the KVStore without changing the `originStorage`.\n- Now, since we have a `dirtyStorage`, it is updated to the previous value A without changing the `originStorage`.\n\nSince the tx executed correctly, the evm calls the commit to persist the dirtyStorage. However, since dirtyStorage is equal to originStorage, nothing will be changed.\n\nTo summarize, 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. \n\n### Severity\n\nBased on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to `Critical` since the attack could have lead to direct loss of funds.\n\n### Patches\n\nThe issue has been patched in versions >=V17.0.0. \n\n## For more information\nIf you have any questions or comments about this advisory:\n\nReach out to the Core Team in [Discord](https://discord.gg/evmos)\nOpen a discussion in [evmos/evmos](https://github.com/evmos/evmos/discussions)\nEmail us at [security@evmos.org](mailto:security@evmos.org) for security questions\n\n\n## Affected packages\n\n- `github.com/evmos/evmos/v16 < 17.0.0`\n- `github.com/evmos/evmos/v7 <= 7.0.0`\n- `github.com/evmos/evmos/v6 <= 6.0.4`\n- `github.com/evmos/evmos/v5 <= 5.0.0`\n- `github.com/tharsis/evmos <= 1.1.3`\n- `github.com/tharsis/evmos/v2 <= 2.0.2`\n- `github.com/tharsis/evmos/v3 <= 3.0.3`\n- `github.com/tharsis/evmos/v4 <= 4.0.2`\n- `github.com/tharsis/evmos/v5 <= 5.0.1`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `github.com/evmos/evmos/v16 17.0.0`","depth":"midnight","depthScore":50,"depthScoreParts":{"impact":50.1,"likelihood":0.2,"exploitation":0,"ransomware":0},"changes":[]}