{"id":"CVE-2024-32644","aliases":["EUVD-2024-1080","GHSA-3fp5-2xwh-fxm6","GO-2024-2715"],"status":"published","title":"Evmos' transaction execution not accounting for all state transition after interaction with precompiles","description":"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 \u003e=V17.0.0.","severity":{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00943,"percentile":0.61463,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-662"],"published":"2024-04-10T22:04:30Z","modified":"2026-10-28T02:31:07Z","fixes":[{"ecosystem":"Go","package":"github.com/evmos/evmos/v16","fixed_in":["17.0.0"],"sources":["ghsa","osv"]},{"ecosystem":"Go","package":"github.com/evmos/evmos/v17","fixed_in":["17.0.0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/evmos/evmos/v16","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"16.0.4"},{"fixed":"17.0.0"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/evmos/evmos/v7","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"7.0.0"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/evmos/evmos/v6","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.0.4"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/evmos/evmos/v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"5.0.0"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/tharsis/evmos","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.1.3"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/tharsis/evmos/v2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.0.2"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/tharsis/evmos/v3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.0.3"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/tharsis/evmos/v4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.0.2"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/tharsis/evmos/v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"5.0.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v16","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"17.0.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v7","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"7.0.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v6","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"6.0.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v5","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"5.0.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"1.1.3"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"2.0.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v3","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"3.0.3"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"4.0.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v5","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"5.0.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v3","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v5","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v6","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v7","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v8","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v9","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v10","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v11","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v12","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v13","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v14","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v15","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v16","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/evmos/evmos/v17","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"17.0.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v3","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/tharsis/evmos/v5","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]}],"products":[{"vendor":"evmos","product":"evmos"},{"vendor":"tharsis","product":"evmos"}],"references":[{"url":"https://github.com/evmos/evmos/security/advisories/GHSA-3fp5-2xwh-fxm6","tags":["x_refsource_CONFIRM","x_transferred","Vendor Advisory","advisory","web"]},{"url":"https://github.com/evmos/evmos/commit/08982b5ee726b97bc50eaf58d1914829648b6a5f","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465","tags":["x_refsource_MISC","x_transferred","Product","web"]},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68","tags":["web"]},{"url":"https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55","tags":["web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-32644","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-3fp5-2xwh-fxm6"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/32xxx/CVE-2024-32644.json","tags":["advisory"]},{"url":"https://github.com/evmos/evmos","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2024-32644","title":"Evmos' transaction execution not accounting for all state transition after interaction with precompiles","description":"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 \u003e=V17.0.0.","status":"published","published":"2024-04-19T14:53:44.423Z","modified":"2024-08-02T02:13:40.251Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-662"],"updated_at":"2026-11-02T14:34:15.337999Z"}],"euvd":[{"id":"EUVD-2024-1080","description":"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 \u003e=V17.0.0.","status":"published","published":"2024-04-19T14:53:44Z","modified":"2024-08-02T02:13:40Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical"}],"updated_at":"2026-11-03T03:50:23.057649Z"}],"ghsa":[{"id":"GHSA-3fp5-2xwh-fxm6","title":"Evmos transaction execution not accounting for all state transition after interaction with precompiles","description":"### 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 \u003e=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","status":"published","published":"2024-04-10T22:04:30Z","modified":"2024-04-19T16:21:00Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-662"],"updated_at":"2026-11-02T14:37:43.62603Z"}],"nvd":[{"id":"CVE-2024-32644","description":"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 \u003e=V17.0.0.","status":"published","published":"2024-04-19T15:15:50.96Z","modified":"2026-06-17T07:30:01.047Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"secondary"},{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical","assessor":"primary"}],"cwes":["CWE-662"],"updated_at":"2026-11-02T14:09:53.50104Z"}],"osv":[{"id":"CVE-2024-32644","title":"Evmos' transaction execution not accounting for all state transition after interaction with precompiles","description":"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 \u003e=V17.0.0.","status":"published","published":"2024-04-19T14:53:44.423Z","modified":"2026-10-28T02:31:07.350818425Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-662"],"updated_at":"2026-11-02T15:44:40.391953Z"},{"id":"GHSA-3fp5-2xwh-fxm6","title":"Evmos transaction execution not accounting for all state transition after interaction with precompiles","description":"### 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 \u003e=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","status":"published","published":"2024-04-10T22:04:30Z","modified":"2026-09-10T03:50:10.906001718Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H","level":"critical"}],"cwes":["CWE-662"],"updated_at":"2026-11-02T15:46:35.747385Z"},{"id":"GO-2024-2715","title":"Evmos transaction execution not accounting for all state transition after interaction with precompiles in github.com/evmos/evmos","description":"Evmos transaction execution not accounting for all state transition after interaction with precompiles in github.com/evmos/evmos","status":"published","published":"2024-06-05T15:10:52Z","modified":"2026-03-03T04:51:46.741224Z","updated_at":"2026-11-02T15:47:01.453823Z"}]}}