ICON Bridge Replay Exploit: How One Signed Message Triggered 1,490 Withdrawals

The ICON bridge replay exploit reportedly reused one valid signed authorization message 1,490 times to trigger withdrawals. The incident was not a failure of a user’s private key; it was a failure to ensure that a signed withdrawal instruction could only be accepted once. For self-custody users, the practical response is to pause interactions with affected bridge contracts and verify official recovery, token, and exchange-status information before depositing or withdrawing.

What changed this week, and why it matters

As of September 2, 2026, ICON’s published post-mortem describes an exploit in its bridge withdrawal flow, while reporting from CryptoSlate says the same authorization message was reused 1,490 times. Read the ICON Network post-mortem for the project’s technical account and the CryptoSlate report for the reported transaction pattern.

This matters to anyone holding their own crypto because bridges sit between two systems: a source chain and a destination-chain contract. A wallet can be working normally while the bridge’s verification or withdrawal accounting is unsafe. If a bridge, exchange, or token issuer pauses deposits, that interruption is often a containment measure rather than evidence that every wallet has been compromised.

The immediate change is operational: affected bridge routes and related exchange flows may be unavailable or treated as unsafe while the incident is investigated. Do not assume that a transaction is safe merely because it is signed, appears in a familiar wallet, or uses a token with the expected name.

How a replay attack works

A digital signature proves that a particular key authorized particular data. It does not, by itself, prove that the authorization is new, unique, or still valid. Those properties must be enforced by the application or smart contract that checks the signature.

A simplified bridge withdrawal may work like this:

1. A user deposits assets on one chain.
2. A bridge system observes the deposit and creates an authorization for a withdrawal on another chain.
3. An authorized signer signs data describing the recipient, asset, amount, and related transaction details.
4. A destination contract checks the signature and releases funds.

A replay vulnerability appears when the contract accepts the same authorization again. If the signed data does not include effective uniqueness controls—or if the contract fails to record that the authorization was consumed—an attacker can submit the old signature repeatedly. The cryptographic signature remains valid each time, even though the business instruction was intended to be one-time-only.

This is different from forging a signature. In a replay attack, the attacker may not need to steal the signer’s private key or break the cryptography. They reuse a message that the system already considers authentic, exploiting a missing or ineffective rule about when that message should stop working.

The controls that normally prevent replay

Secure withdrawal systems commonly combine several safeguards:

• Nonce: a unique number tied to an authorization, with each nonce accepted only once.
• Consumed-message tracking: contract state records that a withdrawal or message identifier has already been processed.
• Domain separation: the signature identifies the intended contract, application, chain, or environment.
• Chain identification: data cannot be moved safely between networks if a signature intended for one chain is accepted on another.
• Exact request binding: the signature covers the recipient, asset, amount, contract, expiry, and other important parameters.
• Expiration: an authorization becomes invalid after a defined time.
• Accounting limits: the system limits cumulative withdrawals or requires additional review for unusual activity.

These controls address different failure modes. A nonce can stop the same request from being accepted twice, while domain separation can stop a signature created for one contract or chain from being used somewhere else. A bridge may use several controls, but one incorrectly implemented check can still create a serious gap.

The ICON incident’s central lesson is therefore broader than one contract: “signed” and “single-use” are separate security properties. A message needs explicit replay protection if the application expects it to authorize only one withdrawal.

Why 1,490 withdrawals could follow one authorization

The reported number does not mean that 1,490 different users necessarily approved 1,490 transactions. It describes repeated use of an authorization in the withdrawal process, according to the reporting cited above. One accepted message can become a template for repeated submissions when the contract does not properly mark it as spent or otherwise enforce uniqueness.

An attacker can automate those submissions. Once the first transaction demonstrates that the contract accepts the authorization, a script can send further transactions, adjust any permitted execution fields, and target available liquidity—depending on exactly what the signed payload and contract logic allow. The result is a payout loop: a single authorization produces many withdrawals instead of one.

The final impact depends on contract balances, token accounting, transaction ordering, and the scope of the vulnerable function. That is why users should avoid guessing from a wallet balance or a single explorer transaction. The official post-mortem and contract-level remediation notice are more useful than social-media summaries.

For a practical framework for evaluating incidents, see our guide to reading a crypto hack post-mortem. It explains how to separate confirmed facts, preliminary findings, and unresolved questions.

Why bridges and exchanges pause deposits

A bridge contract may be able to mint, release, lock, or account for representations of assets across networks. If its withdrawal logic is under investigation, operators may pause one or more of those functions to stop additional losses and preserve evidence.

Exchanges can react even when their own wallets were not directly exploited. A deposit from an affected route may be difficult to classify, may represent an asset whose backing or supply is being reconciled, or may arrive through a contract that the exchange has deliberately blocked. Pausing deposits reduces the chance that an exchange credits funds it cannot later validate or recover.

A pause can affect users in several ways:

• A deposit transaction may confirm on-chain but remain uncredited by the exchange.
• A withdrawal may be delayed while the platform checks token contracts and balances.
• A bridge interface may remain visible even though its contracts are paused.
• A token may trade or display in a wallet while its cross-chain representation is under review.
• Recovery distributions or contract migrations may require users to follow a later official process.

A confirmed transaction is not the same as a confirmed deposit credit. The blockchain can show that a transfer happened, while an exchange’s internal risk and accounting systems refuse to recognize it. Users should not send additional funds to “test” a paused route.

What self-custody users should verify

Self-custody protects access to your keys, but it does not remove smart-contract, bridge, token, or counterparty risk. Your wallet cannot make an unsafe withdrawal contract safe, and a hardware wallet cannot detect every malicious or flawed contract call.

Before interacting with an affected asset or route, use this checklist:

1. Confirm the official incident status

Start with ICON’s official channels and post-mortem. Check whether the specific bridge contract, chain route, token representation, or withdrawal function is listed as affected. Be careful with links in replies, direct messages, and urgent recovery offers; incidents often attract impersonators.

2. Identify the exact contract and network

Do not rely only on a ticker or token name. Compare the contract address, network, bridge route, and official token information. A similarly named token on another chain may be unrelated, while a legitimate token may have multiple representations with different risks.

3. Check whether the contract is paused or upgraded

Review the bridge’s official status page and, where appropriate, the relevant block explorer. Look for pause events, upgrade transactions, administrator announcements, or a migration instruction. Do not interact with a replacement contract unless its address comes from a trusted official announcement and you understand what action it requests.

4. Treat signatures as transaction permissions

A signature request is not harmless just because it does not immediately show a token transfer. Read the message and understand whether it authorizes a withdrawal, permit, approval, delegated action, or other contract operation. If the message is opaque, unusually broad, or unrelated to what you intended to do, reject it.

5. Verify exchange support before depositing

If an exchange says deposits are paused, wait for its own support or status notice. Check the exact network and asset, because support can differ by chain. Never assume that a successful on-chain transfer guarantees an account credit while the route is suspended.

6. Keep records, but do not expose secrets

Save transaction hashes, dates, amounts, destination addresses, and screenshots of official notices. Do not share a seed phrase, private key, recovery file, or wallet backup with anyone claiming to help recover funds. A legitimate incident response team should not need your private key.

Our crypto attack surface map provides a useful way to distinguish wallet-key risk from application, bridge, and exchange risk.

What this does—and does not—say about your wallet

The exploit described here does not automatically mean that every ICON holder’s private key was exposed. A replay flaw can exist in a bridge authorization path while ordinary wallet accounts remain intact. The relevant question is whether you signed or submitted a transaction to an affected application, or whether funds you received depend on the affected bridge’s accounting.

Still, avoid approving unknown replacement contracts or signing messages presented as emergency fixes. If you already interacted with the affected bridge, record the relevant addresses and follow official guidance before revoking, migrating, or moving assets. A rushed response can create a second problem, such as signing a phishing transaction or sending funds to an impersonator.

The broader bridge-security lesson

Bridges turn a simple transfer into a coordination problem involving contracts, signers, relayers, validators, token issuers, and exchanges. Each component must agree on what happened, how many times it happened, and which chain or contract is authorized to act.

Replay protection is one part of that design. Stronger systems also need clear message formats, independent monitoring, withdrawal limits, pause controls, transparent incident communication, and careful upgrade procedures. For users, the takeaway is straightforward: treat a bridge as a separate risk layer, not as an invisible extension of your wallet.

Until ICON and affected service providers publish a clear reopening or recovery process, use the conservative approach: do not bridge through the affected route, do not deposit related assets into a paused exchange, and verify contract addresses through official sources before signing anything. A valid signature can authenticate a message; only correct protocol logic can ensure that message is used once.

This article is for educational purposes and is not financial advice.