ICON Network: Replay Exploit Post-Mortem

August 30, 2026

1. Summary

Between 02:01:02 and 02:21:12 UTC on 27 August 2026, an unauthorized actor ("attacker") exploited a vulnerability in the ICON Network migration contract, replaying two previously legitimate, signed withdrawal messages 1,492 times in a 20-minute window. The replays released 119,866,000 ICX and 531,600 bnUSD into a single attacker-controlled wallet, far more than the original signed messages ever authorized. All assets involved were foundation-held. No user deposits, balances, or positions were accessed or affected.

Most of that ICX moved on to exchange deposit addresses. We believe most of the exploited ICX remain frozen within a couple of exchanges and we are already working on the recovery. The funds confirmed as taken by the attacker are, so far, approximately 150.2 ETH that was converted and withdrawn to the Ethereum network before controls fully took hold, plus a 31,204 USDC portion of total USDC which was borrowed using the exploited ICX and bnUSD as collateral. The previously mentioned 531,600 bnUSD exposure has been fully recovered.

Our monitoring alert fired within seven minutes of the first exploit transaction; our technical staff noticed the anomaly later and the team paused the affected contract. The ICON Network, which is currently controlled by the ICON Foundation during the token migration period, was halted outright, freezing all on-chain balances in place as a precaution: user balances were paused and resumed unaffected once the network restarted. Because the majority of the exploited funds had already reached exchange custody well before that point, pausing ICON-side infrastructure could not by itself stop further movement of the exchange-held portion. We believe a portion of the ICX was still converted and withdrawn as ETH in the hours between the contract-level pause and the full network halt. Exchanges holding affected deposits were formally notified and asked to halt withdrawals and preserve records.

Although this particular contract underwent third party audit and all recommendations were applied, including modifications to this exact area of code, our efforts still fell short. Furthermore, while our monitoring systems successfully flagged the anomaly within minutes, we failed to fully contain the exploit. This incident highlighted an operational gap in translating real time threat detection into immediate human intervention, an issue we are now directly addressing.

A fix for the underlying vulnerability was then deployed as part of the network's restart, and the ICON Network resumed operation at approximately 07:51 UTC on 28 August 2026, roughly 25 hours after the halt.

2. The Root Cause

Root cause components:

• ICON Network migration contract, which converts ICX and bnUSD (ICON) to SODA and bnUSD tokens (Sonic), and back, governing ICX and bnUSD withdrawals through the bridge; and,

• SODAX Asset Manager contract, which processes those withdrawal messages.

The underlying vulnerability: a change intended to standardize withdrawal message data to a fixed 32-byte size introduced an integer-precision defect. Part of each message's serial number was handled through float64-range logic rather than exact integer arithmetic. In practice, this meant the contract's uniqueness check (the guard meant to stop a message from being processed twice) only validated the high bits of the serial number, while the portion actually covered by the cryptographic signature (the low 256 bits) never changed between calls.

The exploit chain: approximately 11 hours before the exploit, the attacker opened an ordinary position on the Sonic side of the protocol, an existing account they would later use to receive and re-collateralize part of the stolen funds. The attacker then took two previously valid, signed withdrawal messages and resubmitted them to the Asset Manager contract 1,492 times between 02:01:02 and 02:21:12 UTC. Within each replay set, the signed payload and signature were identical byte for byte. Only the unsigned high bits of the serial number varied, which was enough to pass the uniqueness check while the actual signature verification kept seeing the same two authorized messages. 1,490 of the 1,492 calls succeeded (2 reverted). Every successful call credited the same attacker-controlled relayer wallet, compounding to a release of 119,866,000 ICX and 531,600 bnUSD.

System discrepancies: none identified to date; the exploit behaved consistently across the transaction set.

3. The Resolution

Immediate containment: Upon technical response to the exploit, withdrawal paths were paused at the rate-limiter that sits in front of the Asset Manager. With that pause active, every further withdrawal message (including any additional replays) reverts before any funds are released. The ICON network was then intentionally halted, freezing all balances in place. Together these two steps stopped the exploit mid-flight and held the remaining reserves. The pause is still in force, can only be lifted by the contract owner, and has no message- or signature-based path to unpause, so the attacker cannot re-open the withdrawal path by replaying anything.

The fix (root cause): We corrected the serialization routine so the serial number is handled with exact, bounded integer arithmetic. Any value that does not fit inside the fixed 32-byte size is now rejected outright rather than silently trimmed to its low bits. Because the number that gets signed and the number used for the uniqueness check are now guaranteed to be identical, a message that has already been processed can no longer be resubmitted under a "new" serial number, the inflated serial numbers the attacker relied on simply revert. The same routine encodes the chain identifiers in every message, so this single change closes every place the defect could appear.

Defense in depth: On top of the root-cause fix, we added an allowlist of authorized relayer addresses to the message-verification path. Withdrawal messages are now only accepted when the transaction originates from a recognized relayer, no matter how many contracts the call passes through on the way in. This ensures that even if an unknown message-handling flaw were ever found in the future, only the protocol's own relayer, never an arbitrary attacker, could submit messages.

Verification: We added a regression test that reproduces the exact attack: it signs a legitimate message, confirms it is accepted once, then replays the identical payload and signature under an inflated serial number and confirms the contract now rejects it and never records it as processed. The full withdrawal/connection test suite passes on a clean build. We also ran an independent adversarial review of the equivalent code on every other chain the protocol supports; that review confirmed this specific serialization defect is unique to the ICON implementation (the other chains use fixed-width integers that cannot exhibit it) and surfaced a small set of unrelated hardening items that are being handled separately.

Safe restart: The system was re-enabled in a strict, verified order: (1) deploy the corrected contract, (2) authorize the relayer on the new allowlist, and (3) only then lift the pause, with each step confirmed on-chain before the next. Any other order would either leave the relayer unable to operate or, if done prematurely, leave the original path open, so the sequence is enforced operationally.

Current status: the ICON Network resumed operation at approximately 07:51 UTC on 28 August 2026, after being paused for roughly 25 hours (halted 06:18:54 UTC, block 117,479,936, on 27 August).

4. Exploited Funds

Scope: All assets involved were foundation-held and no user deposits, balances, or positions were accessed or affected.

Quantifiable losses:

Confirmed net loss to date: approximately 150.2 ETH plus 31,204 in USDC. These figures correspond to the ICX sold and withdrawn before freezes took effect, converted into ETH, plus the unrecovered USDC balance extracted to the same wallet address on the Ethereum chain. Exchanges have confirmed that they froze the accounts holding the ICX, but they are currently unable to share further details on the exact amounts held, converted, and withdrawn until law enforcement authorities are involved. We believe the vast majority of that total is traced, frozen, and in active recovery rather than lost.

Attacker movements: the extracted ICX moved in one hop from the protocol to a single attacker relayer wallet. Between 02:44 and roughly 05:20 UTC, the attacker split 116.5M ICX across multiple deposit addresses of two exchanges: 100.5M ICX to 20 addresses of Exchange A and 16.0M ICX to 4 addresses of Exchange B. A further ~2M ICX sent toward a third exchange was rejected and returned to the attacker, and 1.37M ICX was bridged back to the position the attacker had opened on Sonic roughly 11 hours before the exploit, adding it there as collateral. Each exchange swept its own deposits into a single consolidation wallet, a process that continued for Exchange A until roughly 05:20 UTC. Of the 116.5M ICX that reached the two exchanges, a portion of the ICX is believed to have been sold by the attacker before freezes took effect, and those proceeds are the source of the 150.2 ETH referenced above, the incident's single largest confirmed loss. Those withdrawals occurred after the affected contract was paused (03:53 UTC) but before the network-wide halt took effect (06:18:54 UTC). Pausing ICON-side infrastructure has no reach over funds an exchange has already swept into its own custody. Only the exchanges' own freeze can stop that.

On the Sonic side, the attacker put to use a money market position opened at 15:00:58–15:07:35 UTC on 26 August, roughly 11 hours before the exploit. Starting at 02:05:16 UTC, within minutes of the exploit beginning, the attacker closed out that starter position and supplied the stolen bnUSD, along with SODA acquired by migrating a portion of the exploited ICX, as fresh collateral. Borrowing against that collateral in a repeating loop through 03:21:27 UTC, re-supplying part of each USDC borrow to raise the position's borrowing power before drawing more, the attacker accumulated 113,634 USDC in total, roughly half an hour before the affected contract was paused (03:53 UTC). Of that, 82,430 USDC has been recovered; the remaining 31,204 USDC was sent to the same Ethereum wallet that received the 150.2 ETH described above.

Current status: The Foundation has sent formal freeze-and-preservation notices, with complete transaction records, to the affected exchanges, identifying the deposit and consolidation wallets involved and requesting they identify the account holder(s), maintain the freeze on affected assets, block further ICX-related activity on those accounts, and preserve KYC and transaction records. We are working closely with our legal counsel and law enforcement authorities to obtain this information and recover those assets.

Attacker-controlled addresses, for technical reference:

• Relayer/distribution wallet (ICON), the only funding source of deposits above:

  hx130b7e31ad0fb67c8b0442df308d349202212b88

• Hub wallet (Sonic):

  0x72659d1bcc69f15c62ad7eb0f2311952856f0fec

• EOA (Sonic and Ethereum):

  0xA1b828019B43F92f7E5B6d340ccAFF08228fCB52

Figures above combine on-chain data (independently verifiable) with exchange and team-reported information that may be revised as recovery continues.

5. Security and Audit

Having navigated security incidents in the past, we hold security, independent code auditing, and active system monitoring to the highest standard. We continuously invest resources into proactive code reviews and real time threat detection to safeguard our ecosystem.

The uniqueness check and the signature check were validating different parts of the same message: the uniqueness check looked at the high bits of the serial number, while the signature covered only the low 256 bits. This allowed for a single signed withdrawal to be resubmitted 1,492 times with a varying high-bit value and still pass both checks. It also explains the scale of the loss, with each successful resubmission crediting the same wallet.

The ICON Network migration contract has been through external audit, and the resulting recommendations have since been implemented, including changes to this same area of the code. The relay logic specifically pertaining to this security incident was covered in a dedicated relay audit. This gap between what the uniqueness check validated and what the signature covered fell outside the scope of those findings.

• Full Audit History (link)

• Dedicated Relay Audit (link)

Alongside third party audits, the Foundation performs regular internal code reviews through our technical staff and automated agentic workflows. However, in recent months, we have faced an unprecedented volume of complex attacks. We believe this has been an industry-wide problem as attackers have access to more powerful tools. Despite investing in the latest technologies to detect vulnerabilities and strengthen overall system security, our efforts fell short here.

Our monitoring systems detected the anomaly within minutes of the first exploit transaction. Turning that detection into a fast human response is exactly the gap this incident exposed; see the alerting improvements below.

6. Timeline of Detection and Response

• 15:00:58–15:07:35 UTC, 26 August 2026 (~11 hours before the exploit):

  Attacker opens a money market position on Sonic, supplying 2,000 USDC and borrowing 1,200 bnUSD, establishing the account later reused to receive and re-collateralize stolen funds.

• 02:01:02 UTC:

  Replay exploit begins; 119,866,000 ICX released to the attacker's relayer wallet over the following 20 minutes (through 02:21:12 UTC).

• 02:05:16–03:21:27 UTC:

  Attacker unwinds the dry-run position (repaying 1,199.97 bnUSD) and builds a leveraged money market position from the exploited assets: supplies 66,300 bnUSD and, later, 1,366,000 SODA as collateral, then borrows and re-supplies USDC in a repeating loop across nine transactions, borrowing 113,634 USDC in total against one partial 1,799.89 USDC withdrawal, reconciling exactly with the USDC figure in Section 4.

• 02:08 UTC:

  First monitoring alert fires.

• 02:44–~05:20 UTC:

  Attacker distributes 116.5M ICX to exchange deposit addresses, 100.5M ICX to 20 addresses on Exchange A and 16.0M ICX to 4 addresses on Exchange B, plus 1.37M ICX bridged back to the attacker's Sonic position as additional collateral. Each exchange sweeps its own deposits into a single consolidation wallet.

• ~03:40 UTC:

  Technical staff investigate the anomaly and investigation opens.

• 03:53 UTC:

  Contract related to the exploit is paused.

• 04:13–04:56 UTC:

  A separate attempt to move ~2M ICX through a third exchange is rejected; the funds are returned to the attacker.

• 04:46 UTC:

  Began notifying exchanges of the security incident.

• 05:54 UTC:

  Exchanges begin to suspend ICX deposits and withdrawals as a network-wide precaution.

• 06:18:54 UTC (Block 117,479,936):

  ICON Network is halted outright, freezing all balances in place to prevent further spread of stolen ICX.

• Following containment:

  Formal freeze-and-preservation notices, with complete transaction records, sent to affected exchanges; receiving accounts frozen at the Foundation's request.

• Ongoing:

  bnUSD fully recovered; USDC recovery in progress; legal counsel engaging law enforcement authorities.

• 28 August 2026, ~07:51 UTC:

  ICON Network resumes operation, roughly 25 hours after the halt, with the fix for the underlying flaw deployed as part of the restart.

7. Next Steps and Improvements

The roughly 90 minutes between the first automated alert (02:08 UTC) and a full incident response was primarily an alert-tuning issue rather than a detection gap. This alert type had previously fired often during unrelated RPC connectivity incidents, so it was configured at a severity that does not page the on-call team suitably. More sensitive alerting and an automatic-disable capability had already been built to address this, but were not yet enabled because of that same false-positive rate; tuning work over the past two months has brought false positives down substantially, and turning on the automatic-shutdown trigger is now one of the concrete next steps below. More broadly, the posture on automatic stops and hard limits is shifting to trip more readily by default, accepting more frequent service disruptions as the cost of containing the next anomaly faster, rather than tuning them down out of concern for how often they fire.

Immediate:

• Fix correcting the message-uniqueness check deployed as part of the ICON Network's restart on 28 August 2026.

• Enable the automatic-shutdown trigger for this alert class, now that recent tuning has brought its false-positive rate under control.

• Continue direct coordination with the affected exchanges, and any other exchanges holding affected funds, to trace, freeze, and pursue return of deposits.

Process improvements:

• Reset the default thresholds on automatic circuit-breakers and hard limits across the protocol to trip more readily, favoring more frequent, contained disruptions over slower, larger ones.

• Expand test coverage specifically for replay and message-uniqueness edge cases in bridge withdrawal handling.

• Formalize the incident response runbook based on the detection-to-containment timeline from this event.

Long-term commitments:

• Commission a targeted follow-up audit of the message-uniqueness and replay-guard logic specifically, since this incident surfaced a gap that fell outside the scope of prior audit findings.

• Publish a follow-up recovery update once USDC recovery and exchange coordination are further along.

No user deposits, balances, or positions were accessed or affected. Once we have more comprehensive information from the exchanges involved, we will assess whether any further remedial action is required and share any such findings and steps.