CVE-2024-32644: Evmos transaction execution not accounting for all state transition after interaction with precompiles

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.9%, percentile 61: FIRST’s model estimates a 0.9% chance of exploitation activity in the next 30 days, higher than 61% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes github.com/evmos/evmos/v16 (Go) <= 16.0.4, fixed in 17.0.0; github.com/evmos/evmos/v7 (Go) <= 7.0.0, no fixed version listed; github.com/evmos/evmos/v6 (Go) <= 6.0.4, no fixed version listed; github.com/evmos/evmos/v5 (Go) <= 5.0.0, no fixed version listed. Check your lockfile, including transitive dependencies.

What it is

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.

From the GitHub advisory

Context

- stateObject: 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: 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. Setting the new state means we update the Cosmos SDK KVStore.

Below, are described the steps to perform the attack:

Weakness type: CWE-662.

Product: github.com/evmos/evmos/v16 (Go) · Assigned by: GitHub_M · Published: 2024-04-19

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: none (no login)
• User interaction: none
• Scope: unchanged

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.94% probability of exploitation activity in the next 30 days; percentile 61.

Timeline

• 2024-04-10 — GitHub-reviewed advisory GHSA-3fp5-2xwh-fxm6 published (critical)
• 2024-04-19 — CVE record published by GitHub_M
• 2024-08-02 — CVE record last updated

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-3fp5-2xwh-fxm6 github.com
2. CVE.org record CVE-2024-32644 cve.org
3. NVD entry CVE-2024-32644 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. github.com github.com
5. github.com github.com

Critical Go advisories · Today’s Security Digest