ICON Foundation Replay Exploit Reused Withdrawal Message 1,490 Times

A replay vulnerability in ICON’s withdrawal contract was exploited on August 27, resulting in the release of 119,866,000 ICX and 531,600 bnUSD from foundation‑held assets. The attack reused two legitimate withdrawal messages 1,490 times without accessing user deposits or balances.

How the Flaw Worked

The contract’s uniqueness check relied on a serial‑number field that was altered to a 32‑byte format. This change caused the high bits of the serial number to be processed using float64‑range logic instead of exact integer arithmetic. Consequently, the contract compared the high bits— which the attacker could vary— while the cryptographic verification covered the unchanged low 256 bits. The signed payload and signature remained identical, allowing each call to appear unique to the contract.

Timeline of the Attack

• 02:08 UTC – Monitoring system triggered an alert, seven minutes after the exploit began.
• 02:44 UTC – Attacker started splitting ICX to exchange deposit addresses.
• 03:40 UTC – Technical staff began investigation (92‑minute gap).
• 03:53 UTC – Affected contract was paused (105 minutes after the alert).
• 05:20 UTC – Distribution of funds to exchanges ceased.
• 06:18:54 UTC – Network halted.
• 07:51 UTC (next day) – Network resumed after roughly 25 hours.

Financial Impact

ICON reports a net loss of approximately 150.2 ETH and 31,204 USDC. Most of the released ICX has been traced, frozen, and is under active recovery. bnUSD and SODA were recovered in full, while the exact amount of ICX held on exchanges remains uncertain.

Response and Audits

The contract was paused, and the network was temporarily halted to contain the exploit. Public notices from Bitvavo, Bitget, and KuCoin confirmed suspension of ICX deposits and withdrawals, though none disclosed the amount of attacker‑controlled funds. A November 2025 relay audit reviewed related code but did not include the affected migration‑contract source, and none of its findings flagged the serial‑number mismatch.

Key Takeaways

The incident highlights the risks of mismatched data handling in smart‑contract implementations and the importance of rapid detection and response mechanisms.