# Replacing ICA active channel during the upgrade and a bit more

Non-atomic check-then-act in ibc-go ICA handshake lets an attacker replace the active ICA channel with a malicious one during a channel upgrade, changing encoding.

- Payout: hidden
- Severity: low
- Program: Cosmos
- Found by: unknown_feature
- Disclosed: 2025-06-30
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/2917368
- Library page: https://bugbountylibrary.com/r/h1%3A2917368
- Tags: area:web3 domain:web3 impact:integrity kind:bounty platform:hackerone sev:low tech:solidity technique:race-window technique:source-review vuln:business-logic vuln:race-condition

**Target:** ibc-go ICA controller/host handshake keepers
**Root cause:** Active channel is set via non-atomic check-then-act in controller channel ack and host channel open confirm; GetOpenActiveChannel ignores FLUSHING state, so a malicious channel can be acked/confirmed during the victim channel's upgrade window and become active.
**Steps:**
1. Monitor newly inited ICA channels on source chain; iterate returned channels to find a match.
2. During window between ICA chan init on controller and chan open confirm on host, submit `chan init` with ICA port/connection on controller and `chan try` on host for attacker channel (channel-2).
3. Wait for victim channel (channel-1) to start upgrading via gov proposal changing encoding; attacker channel keeps old encoding.
4. Once proposal passes, complete handshake for malicious channel in parallel with upgrade sequence; `MsgChannelOpenAck` succeeds because GetOpenActiveChannel does not return FLUSHING channel-1.
5. Host open confirm also passes non-atomically, setting channel-2 as active ICA channel with different encoding.
**How found:** Code review of ICA handshake: noticed active channel set on controller during channel ack is a check-then-act and GetOpenActiveChannel only returns OPEN channels, not FLUSHING; similarly host open confirm check is non-atomic and includes FLUSH states. Hypothesized a race window during upgrade.
**Exploitation:** Attacker races the ICA handshake during a channel upgrade: pre-creates a parallel channel with old encoding, waits for the legit channel to enter FLUSHING during upgrade, then completes ack/open-confirm so the malicious channel becomes the active ICA channel. Cannot change ICA address or connection, only encoding, which breaks host deserialization of ICA txs until another upgrade.
**Escalation:** Pre-setup multiple malicious channels, one per future upgrade, to repeatedly hijack the active channel.
**Insight:** When auditing IBC/ICA handshake code, look for check-then-act on channel state where the getter filters by OPEN only — FLUSHING/upgrade states create windows where a parallel channel can be acked and become active.