# Making transfer v2 channel unupgradable through the forwarding

Transfer v2 forwarding lets a malicious channel leave unacknowledged packet commitments on a legit channel, blocking it from reaching FLUSHCOMPLETE and thus unupgradable forever.

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

**Target:** IBC transfer v2 channel upgrade / packet forwarding
**Root cause:** Forwarded packets only write an acknowledgement after the downstream channel acks; a malicious downstream channel can withhold acks, leaving committed packets on the legit channel that HasInflightPackets sees, preventing FLUSHCOMPLETE and upgrade completion.
**Steps:**
1. Set up two chains ibc-0/ibc-1 with legit transfer v2 channel-0<->channel-0 via relayer.
2. Open attacker channels channel-1 on ibc-0 and channel-1 on ibc-1 through a proxy chain.
3. Submit ReceivePacketV2 on channel-1 of ibc-0 with Forwarding hops `[{legitChannel, port}, {ibc0Path.Dest.ChanId, port}]`.
4. Packet forwards via legit channel-0 to ibc-1 then to attacker channel-1 on ibc-1, writing receipt but no ack.
5. Attacker channel never acks; legit channel-0 on ibc-0 retains inflight commitment.
6. Attempt channel upgrade: HasInflightPackets blocks FLUSHCOMPLETE, ChanUpgradeOpen errors, upgrade never completes.
**How found:** Reading upgrade logic: HasInflightPackets gates FLUSHCOMPLETE, and commitments are only deleted via ack or timeout. Noticed forwarding only writes ack after downstream ack, creating a dependency on a potentially malicious channel; hypothesized a non-acking channel could pin commitments forever.
**Exploitation:** Attacker opens a channel to the victim chain and crafts a forwarded transfer packet whose hops route through the victim's legit channel to an attacker-controlled channel that never acknowledges. The receipt is written but no ack, so the commitment on the legit channel persists indefinitely (cannot be timed out since receipt exists), permanently blocking upgrades.
**Insight:** When a protocol's state machine gates progress on a counter of outstanding items, look for paths where an external party controls whether those items ever resolve—here forwarding defers ack-writing to an attacker-chosen downstream channel, turning a liveness counter into a griefing lever.