Secret Network Exploit

Axelar’s core protocol was not affected. The impact is confined to Secret-wrapped versions of Axelar assets on the Secret↔Axelar channel-69 / channel-61 IBC connection; no other chains, assets, IBC channels, or escrow accounts were affected, and no action is needed.

On June 10, 2026, an attacker exploited an ‘infinite mint’ bug in a vulnerable IBC-enabled smart contract on Secret Network ( secret-4 ) to mint unbacked, Secret-wrapped versions of Axelar-wrapped assets ( saTokens ), then redeemed them back over the legitimate IBC channel to drain the real Axelar-wrapped assets held in escrow on Axelar. The smart contract, a modified CW20-ICS20 implementation deployed on Secret, did not verify the source channel of inbound IBC packets before minting, so deposits forged over an attacker-controlled channel minted genuine saTokens with no assets backing them. Approximately $4.67M worth of tokens were drained.

The Inter-Blockchain Communication protocol (IBC) lets independent Cosmos chains exchange messages and tokens. Instead of a trusted intermediary, IBC secures each channel with light clients. For each counterparty chain, both chains run an on-chain light client of the other, tracking the counterparty’s validator set and block headers. This setup allows the light client to confirm whether some event happened on the other side, without needing to trust any external validators. To deliver an IBC packet, a relayer submits the packet together with a proof that this packet was committed on the source chain. The destination chain verifies that proof against its light client’s stored consensus state before accepting it. IBC relaying is therefore permissionless and trust-minimized, by only needing to trust the counterparty’s IBC implementation and chain validators.

Through IBC channels, any token can be transferred. When a token is sent to a chain from which it doesn’t originate, it is escrowed (locked) on the source chain and a wrapped voucher is minted on the destination chain. When that voucher is later sent back over the same channel, it is burnt on the destination side and the original token is unlocked on the source side. This accounting is per-channel: Each channel has its own escrow account, and a voucher carries a denomination path tied to the channel it came through, so it can only be redeemed over that same channel. This isolation is what keeps channels from interfering with each other. This isolation and correct handling of denomination paths must be enforced by all IBC implementations.

Opening IBC connections is permissionless. Anyone can stand up a new chain A , create a light client of a target chain B , open a connection and a channel, and begin transferring assets they hold. This is by design and harmless if IBC is implemented correctly: Tokens bridged in over a new channel receive a fresh, distinct denomination and have their own escrow, so they are not fungible with assets that arrive over other channels.

The Secret Network (chain id secret-4 ) connects to Axelar mainnet (chain id axelar-dojo-1 ) over the IBC channel axelar-dojo-1 transfer/channel-69 ↔ secret-4 wasm.secret1yxjmepvyl2c25vnt53cr2dpn8amknwausxee83/channel-61 , allowing both plain token transfers as well as token transfers carrying GMP messages to pass between these two networks. On the Secret Network side of this IBC connection, a smart contract handles receiving IBC messages and mints “Secret Axelar Wrapped Tokens” ( saTokens such as saUSDC, saWBTC, and saDAI), wrapping the bridged Axelar assets in Secret’s privacy-preserving SNIP-20 token standard, so that the resulting balances are encrypted on-chain.

The root cause was a modified CW20-ICS20 IBC-enabled smart contract ( github.com/scrtlabs/ics20-for-axelar , with Code ID 2446 , deployed at secret1yxjmepvyl2c25vnt53cr2dpn8amknwausxee83 ): It minted vouchers without verifying the source of the inbound transfer. The deployed contract is a fork of Secret’s SNIP-20 ICS-20 implementation ( github.com/scrtlabs/snip20-ics20 ), modified for the Axelar↔Secret IBC connection ( github.com/scrtlabs/ics20-for-axelar ).

The defect lived in do_ibc_packet_receive , where the two checks that bind a voucher to the channel it arrived on were commented out :

What remained rejected denoms containing a / and minted any bare denom present on the allow-list. Because that allow-list was keyed by denom name rather than by channel, a uusdt arriving on the attacker’s channel-227 was indistinguishable from one arriving on Axelar’s legitimate channel-69 : Both minted the same saUSDT, but only the latter had anything escrowed behind it. Because opening an IBC channel is permissionless, the attacker was free to connect a chain under their own control, running a single validator, and self-relay forged deposits into it.

The attack followed directly from this: The attacker spun up a fake chain, opened an IBC channel to Secret, and sent over bare denoms (carrying no source-channel path prefix) whose names matched the allow-list. The contract minted genuine saTokens with nothing backing them. Each forged deposit was sized to the saToken’s entire circulating supply, so redeeming the minted balances back over the Axelar channel released exactly the backing held in the IBC escrow on the Axelar side.

The vulnerability was not introduced by a recent change. It was present in the codebase from the repo’s initial commit on January 15, 2023, and deployed on Secret mainnet on March 30, 2023 (with Code ID 872 ), uploaded by secret1mryld3gd05c7gtm36hfq64emdv54djz7rcmfva , with codehash 2976a2577999168b89021ecb2e09c121737696f71c4342f9a922ce8654e98662 , and instantiated the same day with contract address secret1yxjmepvyl2c25vnt53cr2dpn8amknwausxee83 .

On March 5, 2026 (Secret block 24186627 , MsgMigrateContract A049548A...ACADB8B5 ), the migration admin secret1lrnpnp6ltfxwuhjeaz97htnajh096q7y72rp5d migrated the contract to Code ID 2446 , uploaded by secret1f2jrcqsx7glyta39c6tum2lhk5kh2a0ty6r9ms , codehash ba26d9bcba2901300a53343b7aa9e71095afa149ae18ee1772a64d1a7e5add2f . This migration changed the deployed bytecode (the add-migration-message branch added a memo field and the migrate message itself) but carried the same missing source verification forward. The June 10 exploit struck this migrated code, Code ID 2446 (HEAD b206182 , “fix reproducible build”, January 27, 2026).

Approximately $4.67M worth of tokens were minted without backing, across saUSDT, saUSDC, saDAI, saWETH, saWBTC, saWBNB, and sawstETH, and then redeemed back over the legitimate channel to Axelar. The drained balance represented the real assets that users had bridged into Secret over this connection. With the Axelar IBC escrow account for channel-69 now effectively empty, those assets can no longer be bridged out of Secret. The impact is confined to the seven saTokens on this connection. No other Axelar chains, assets, IBC channels, or escrow accounts were affected.

We detected the incident through our firewalling functionality, which prevented contamination to other chains. The Axelar Emergency Committee disabled the Secret↔Axelar connection. Squid disabled Secret on its frontend. The Secret team was notified to halt and migrate the affected bridge contract.

Once the saTokens had been redeemed, the attacker unescrowed the real tokens from the IBC escrow account on Axelar, moved everything to Ethereum, converted it all to ETH, and split it across multiple wallets, eventually depositing the funds into exchanges. It happened in six steps, all on June 10, 2026:

The attacker’s destination wallet on Ethereum is 0x6c2eAB82bA2897A6E99FB6Af018020dA15123976 . The attacker’s Axelar address is axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8 .

Timeline: 19:33-19:36

The attacker withdraws the newly minted tokens over channel-61 to Axelar axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8 , and Axelar’s channel-69 escrow account unlocks the equivalent amount of locked tokens. This is step 2 in the visualization.

Timeline: 19:38-19:56

The attacker moved the tokens off Axelar to Osmosis through 18 IBC transfers, sent in 3 batches between 19:38 and 19:56 UTC. Each transfer carried a packet-forwarding memo (the Skip/PFM convention), instructing each chain along the route to immediately forward the tokens to the hop rather than hold them, so the whole multi-hop path executed automatically without manual relaying. Batches 1 and 2 each contained one transfer for each of the 7 stolen assets; batch 3 contained 4 retries (WETH, USDT, DAI, wstETH). WBNB, WBTC, and USDC were not retried in batch 3, leaving the residual amounts that appear in the leftover paragraph below.

From Osmosis, the funds reached Ethereum via two routes:

Every bridged transfer converged on a single Ethereum wallet, 0x6c2eAb82Ba2897A6e99fB6aF018020da15123976 . The tokens routed through Axelar were bridged via Axelar’s GMP Gateway, while new USDC was minted via CCTP. The amounts that arrived are listed below:

Not all of the assets were bridged out of Axelar. Roughly 6.2 WBTC, 239k USDC, 64 WBNB, and 248 AXL were left in the attacker’s Axelar wallet. These stranded amounts match the leftover funds we identified in the escrow during the investigation.

Timeline: 20:04-20:15

From the destination wallet the attacker swapped each token for WETH on CoW Protocol, then unwrapped the WETH into native ETH:

The swaps returned 1,456 WETH (689.22 + 392.04 + 245.23 + 107.24 + 21.83). Added to the 893 WETH that had bridged in as WETH already, and unwrapped to native ETH (for example 0x3984f61c...b801d84b and 0xa3b05a11...72c236ff ), this left roughly 2,350 ETH (≈$4M) sitting in this Ethereum wallet.

Timeline: 20:51 the same day to 09:19 the

The attacker then split the ≈2,350 ETH into 30 transfers of 50-139 ETH each, sending them to fresh wallets. A few of the transfers:

25 more followed in the 50-100 ETH range over the same window.

The attacker moved ETH into KuCoin (1,199 ETH), ChangeNow (1,050 ETH), and HitBTC (100 ETH):

From those 30 wallets the funds moved on to three exchanges, usually in a single hop, sometimes through one or two intermediate wallets first.

KuCoin (1,199 ETH across 15 deposits to 0x45300136...d992b785 ):

ChangeNow (1,050 ETH across 13 deposits to 0xEbA88149...DE94cB1 ):

HitBTC (100 ETH across 2 deposits to 0x80787af1...d7Ee1A ):

Root cause : The bridge minted saTokens against a denom’s name without verifying the source channel of the inbound packet. The allow-list decided which denoms were mintable but never checked whether a transfer actually arrived over the channel holding the backing, so a forged deposit over an attacker-controlled channel minted genuine, unbacked saTokens. A mint must be authorized by the packet’s source channel, not the denom name alone.

Contributing factors:

Both contracts were compiled on amd64 (x86_64) and optimized with wasm-opt -Oz . The Secret Network codehash is the sha256 of the uncompressed optimized .wasm .

Code 872 was a local build, so its absolute paths are baked into the binary. For a byte-exact hash you must replicate them ( /mnt/d/scrtlabs/ics20-for-axelar and CARGO_HOME=/ /tovi/.cargo ).