CVE-2022-24738

Executive Summary

CVE-2022-24738 is a critical vulnerability in Evmos, the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network, affecting all versions prior to 2.0.1. An attacker can drain unclaimed funds from user addresses by creating a malicious Cosmos chain that bypasses signature verification, connecting it to the target Evmos instance, and using this joined chain to transfer funds. The vulnerability carries a CVSS score of 8.1 (High) and has no known workarounds, requiring an upgrade to version 2.0.1 to remediate. The attack vector is network-based and requires no authentication but demands a nuanced understanding of Cosmos interchain communication, elevating the attack complexity.

Technical Analysis

Evmos is built on the Cosmos SDK and functions as an EVM-compatible chain, enabling Ethereum-style smart contracts while leveraging Cosmos' Inter-Blockchain Communication (IBC) protocol for cross-chain asset transfers. The vulnerability resides in the chain's handling of cross-chain transactions, specifically in the verification of signatures during the IBC handshake and fund transfer processes.

In versions prior to 2.0.1, when Evmos receives a transaction from a connected chain, it fails to validate that the originating chain properly enforced signature verification. An attacker exploits this by standing up a new Cosmos chain configured to disable or bypass signature checks (e.g., by misconfiguring the consensus or auth module). Once this malicious chain is established, the attacker initiates an IBC connection with the target Evmos instance.

The attack mechanism hinges on Evmos accepting the malicious chain's state proofs and transaction data without independent cryptographic verification. Because the interconnected chain does not enforce signatures, the attacker can submit transactions on the malicious chain that claim to transfer unclaimed funds from any user address on Evmos. The Evmos instance, trusting the IBC connection, processes these claims and releases the funds to the attacker-controlled address.

This flaw classifies under Improper Access Control (CWE-284) because the access control mechanism (signature verification) is delegated to an untrusted external component without fail-closed validation. The attack surface is the IBC protocol layer, which is exposed on any public-facing Evmos RPC/API endpoint. The complexity is high due to the need to operate a separate blockchain and successfully complete an IBC handshake, but the absence of authentication requirements and the direct financial impact justify the 8.1 CVSS rating.

Exploitation Scenarios

The attack chain is inferred from the NVD description as follows:

1. Reconnaissance/Target Identification: The attacker identifies publicly accessible Evmos nodes (versions < 2.0.1) via network scanning (e.g., Shodan for open Cosmos RPC ports, typically 26657 for Tendermint RPC and 8545 for EVM JSON-RPC) or by monitoring chain registries. The target must have an active IBC connection or be configured to accept new inbound IBC connections.

2. Triggering the Flaw: The attacker sets up a Cosmos chain (e.g., using the Cosmos SDK) with signature verification explicitly disabled in the authentication module. This is achieved by modifying the chain's genesis configuration or transaction handling logic. The attacker then establishes an IBC connection between this malicious chain and the target Evmos instance, performing the standard IBC handshake (ChanOpenInit, ChanOpenTry, ChanOpenAck, ChanOpenConfirm).

3. Payload/Execution Method: Once the IBC channel is established, the attacker crafts an ICS-20 (fungible token transfer) packet or a custom IBC message on the malicious chain. Because signature verification is disabled on the malicious chain, the attacker can authorize transactions on behalf of any Evmos user address without holding the corresponding private key. The malicious chain produces a state proof for this transaction, which is relayed to the Evmos instance. Evmos, lacking independent verification, accepts the proof and executes the transfer to the attacker's address.

4. Post-Exploitation Impact: The attacker drains all unclaimed funds (balances not actively managed by users) from addresses on the Evmos instance. The stolen assets are transferred to attacker-controlled addresses on the malicious chain or subsequently bridged to other chains for laundering. The attacker can repeat this process across multiple IBC channels or continuously drain new unclaimed balances. The integrity of the Evmos chain is compromised, and user trust is severely degraded.

No public PoC is available; the attack chain is inferred from the vulnerability class and public vulnerability description.

Impact Assessment

The primary impact is complete loss of confidentiality and integrity of user funds on the affected Evmos instance. The CVSS vector (approximated: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) highlights that:

• Confidentiality (High): Attacker gains access to and can move funds they do not own.
• Integrity (High): The attacker can arbitrarily modify on-chain balance states.
• Availability (High): Although not explicitly stated, draining funds can destabilize the chain's economic model, potentially triggering panic selling or de-pegging of bridged assets.

The blast radius extends beyond the direct victim. The exploit undermines the foundational trust in IBC as a secure cross-chain mechanism, potentially affecting the broader Cosmos ecosystem. Enterprises operating Evmos validators, dApps, or those holding funds through the chain face immediate financial loss. Given the CVSS score of 8.1 and the absence of workarounds, any unpatched instance is critically exposed.

Detection Guidance

Detection of this attack is challenging due to the lack of public PoC and the rarity of the exploitation technique. The following rules focus on anomalous IBC connection behavior and unexpected cross-chain fund transfers.

Sigma Rule

title: Suspicious IBC Channel Creation to Evmos Node
id: 3f6b8f1e-7c42-4a9b-8d2f-1a5c3e7d9b01
status: experimental
description: Detects creation of new IBC channels from unknown or unverified chains, potentially indicating CVE-2022-24738 exploitation attempts.
logsource:
  product: evmos
  service: tendermint
detection:
  selection:
    event_type: "ibc_channel_open_init"
    counterparty_chain_id: "*"
  filter:
    known_chain_ids:
      - "cosmoshub-4"
      - "osmosis-1"
      - "evmos_9001-2"
  condition: selection and not filter
level: high
tags:
  - attack.t1190
  - cve.2022.24738

YARA Rule

rule Evmos_IBC_Signature_Bypass
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects potential IBC handshake messages with missing signature verification fields, indicative of CVE-2022-24738 exploitation"
        cve = "CVE-2022-24738"
        date = "2024-01-01"
    strings:
        $sig_disabled = "signature_verification" ascii wide nocase
        $ibc_handshake = "ChanOpenInit" ascii wide nocase
        $unclaimed = "unclaimed_funds" ascii wide nocase
    condition:
        uint16(0) == 0x5A4D and 2 of them  // 0x5A4D is 'ZM' for zip archives (malicious chain binary)
}

Suricata IDS Rule

alert tcp any any -> any 26657 (msg:"CVE-2022-24738 Evmos IBC Unverified Chain Connection Attempt"; flow:to_server; content:"ChanOpenInit"; nocase; content:"/ibc/core/channel"; nocase; content:"counterparty"; nocase; content:"unverified"; nocase; distance:0; classtype:attempted-admin; sid:20224738; rev:1;)

Elastic Detection

sequence by destination.ip with maxspan=5m
  [network where event.category == "connection" and destination.port == 26657 and process.name == "evmosd"]
  [network where event.category == "connection" and destination.port == 26657 and process.name == "evmosd" and network.protocol == "tcp"]
  [event where event.action == "ibc_channel_open" and event.outcome == "success" and ecs.version == "1.10.0"]

Splunk SPL Query

index=evmos_prod sourcetype=tendermint
| search "ibc_channel_open" OR "ChanOpenInit"
| where NOT (chain_id IN ("cosmoshub-4", "osmosis-1", "evmos_9001-2"))
| stats count by source_ip, chain_id, _time
| where count > 1
| eval severity = "high"
| table _time, source_ip, chain_id, count

Wazuh OSSEC Rule

<group name="evmos,">
  <rule id="100247" level="10">
    <decoded>ibc_channel_open_init</decoded>
    <field name="counterparty_chain">\.!signature_verification</field>
    <description>Evmos CVE-2022-24738: New IBC connection from chain without signature verification detected.</description>
    <group>attack.t1190,cve.2022.24738,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 — the vendor has released a fix (version 2.0.1), but no patch evidence from independent sources confirms adoption. The following steps are recommended:

1. Immediate Mitigations:

   • Restrict inbound IBC connections: For any node not actively requiring new IBC channels, configure the hermes/relayer to reject unknown chain IDs and whitelist only trusted counterparty chains.
   • Place the Evmos RPC/Tendermint endpoints behind a firewall or reverse proxy, limiting access to only known relayers and authorized operators.
   • Monitor all pending and active IBC channels for anomalous transactions, specifically transfers from addresses with no prior transaction history.

2. Patch/Upgrade Steps:

   • Upgrade all Evmos nodes to version 2.0.1 or later. Downgrade is not recommended.
   • Coordinate with validators and stakers to ensure a coordinated upgrade, as the fix modifies consensus-critical IBC handling logic.
   • After upgrade, audit all existing IBC connections and channel states; close and re-establish channels if any suspicious counterparty chains are present.

3. Long-Term Hardening:

   • Implement a chain-registry allowlist in the relayer configuration that only permits connections to chains with verified governance.
   • Harden the auxiliary malicious chain detection by monitoring for chains with unusual genesis parameters or modified auth modules — this may involve running a canary node that announces as a honeypot.
   • Participate in the Cosmos ecosystem's bug bounty programs to encourage responsible disclosure of similar IBC flaws.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-24738
2. GitHub Advisory: https://github.com/tharsis/evmos/security/advisories/GHSA-XXXX (referenced as the initial CNA publication, full URL not available in provided data)
3. Evmos Official Repository: https://github.com/tharsis/evmos (release notes for v2.0.1)
4. Cosmos IBC Documentation: https://ibc.cosmos.network/ (context on IBC protocol mechanics)
5. CISA KEV: Not listed (as of writing).

As of the time of writing, there is no evidence of exploit-in-the-wild activity, and no specific threat actor campaigns have been attributed to this vulnerability. However, the high CVSS score and direct financial incentive make exploitation by opportunistic malicious actors likely once a PoC circulates in private channels.