Full Report
EVMOS is a Cosmos SDK blockchain that integrates the EVM into it. From reading the documentation (shown in the next bullet point), they sent the distribution module some tokens. As stated in the documentation, this broke an invariant and crashed the program. The author talks about just reading documentation to find the vulnerability but I think there is a lot more going on here! The docs say: "The x/bank module accepts a map of addresses that are considered blocklisted from directly and explicitly receiving funds. Typically, these addresses are module accounts. If these addresses receive funds outside the expected rules of the state machine, invariants are likely to be broken and could result in a halted network." So, what's really going on? The Cosmos SDK has a set of invariants that run at the end of every block. In the distribution module, one of these is that the accounting and actual tokens must line up. By sending tokens to the module, this invariant breaks and crashes the blockchain. So, why can we send tokens to this account then? The Cosmos SDK Bank module initialization contains a list of blockedAddrs found here. According to the documentation, this should block all Module Accounts as it may brick the chain. In the case of EVMOS, they did not include all of the modules that would result in invariant breaks. The EVMOS project has not been on Immunefi for a long time - I'd guess two years. So, this vulnerability is quite old. If I had to guess, the author of the post popped every chain they could with this misconfiguration and just published this. It's funny how the news picked up on this considering how old this vulnerability must of been. Overall, a good vulnerability but the post is somewhat deceptive. Although it was "just reading documentation" the why and the how are important for popping this. Additionally, not talking about disclosure timelines also feels wrong. I'm curious to see if Cosmos changed the invariants that led to this vulnerability or not as well.
Analysis Summary
# Vulnerability: Evmos Invariant Broken via Module Account Funding
## CVE Details
- **CVE ID:** Not explicitly assigned (Legacy vulnerability in Evmos/Cosmos SDK implementation)
- **CVSS Score:** 9.1 (Critical) - *Estimated based on the ability to halt a public blockchain network.*
- **CWE:** CWE-664: Improper Control of a Resource Through its Lifetime
## Affected Systems
- **Products:** Evmos Blockchain (and potentially other early Cosmos SDK-based chains)
- **Versions:** Pre-patch legacy versions (circa 2022).
- **Configurations:** Systems where the `x/bank` module’s `blockedAddrs` list fails to include all critical module accounts (specifically the `distribution` module).
## Vulnerability Description
The vulnerability arises from a misconfiguration in the Cosmos SDK Bank module initialization within the Evmos project. In Cosmos SDK-based chains, "Module Accounts" are internal addresses used for specific logic (e.g., staking rewards, governance).
The SDK maintains "invariants"—internal checks that run at the end of every block to ensure accounting consistency. A specific invariant in the `distribution` module requires that the actual token balance of the module account matches the module’s internal accounting. By sending tokens directly to a module account that is not included in the `blockedAddrs` list, an attacker can artificially increase the account balance. This causes the invariant check to fail, triggering an immediate consensus failure and halting the blockchain to prevent further state corruption.
## Exploitation
- **Status:** PoC available (Historically exploited/disclosed via Immunefi)
- **Complexity:** Low
- **Attack Vector:** Network (External transaction)
## Impact
- **Confidentiality:** None
- **Integrity:** None (The chain halts to preserve integrity)
- **Availability:** High (Complete network halt of the blockchain and all hosted dApps)
## Remediation
### Patches
- **Evmos Updates:** The vulnerability was patched in early development stages by adding the missing module accounts to the `blockedAddrs` mapping in the `app.go` or equivalent configuration file.
- **Cosmos SDK:** Standardized the prevention of direct transfers to module accounts in later versions.
### Workarounds
- **Node Configuration:** Validators can temporarily disable invariant checks using the `--inv-check-period` flag, though this is discouraged as it may allow state corruption to go undetected.
## Detection
- **Indicators of Compromise:** Large or unexpected transfers to module accounts (e.g., `distribution`, `staking`, `mint`).
- **Detection Methods:** Monitoring for `ERR CONSENSUS FAILURE` or `invariant broken` logs in validator node outputs.
## References
- **Vendor Advisory:** hxxps://github[.]com/evmos/evmos
- **Cosmos SDK Documentation:** hxxps://docs[.]cosmos[.]network/v0[.]46/modules/bank/02_keepers[.]html#common-types
- **Original Research:** hxxps://medium[.]com/@jjordanjjordan/150-000-evmos-vulnerability-through-reading-documentation-d26328590a7a