OAK — OnChain Attack Knowledge

Worked example · 2026-06

Secret Network — a forked CW20-ICS20 bridge contract skips source-channel and escrow checks, minting unbacked tokens redeemed over the real Axelar route — Secret Network / Axelar (Cosmos IBC) — 2026-06-10

Loss
~$4.67M realised. On 2026-06-10 an attacker minted unbacked Secret-wrapped (sa*) tokens on Secret Network and redeemed them over the legitimate Axelar IBC route, draining the real escrowed backing assets. Per the Common Prefix post-mortem the drained assets were seven sa* tokens: saWETH (~$1.54M), saUSDT (~$1.12M), saWBTC (~$1.07M), saUSDC (~$0.64M), saDAI (~$0.17M), saWBNB (~$0.10M) and sawstETH (~$0.04M). The theft went unnoticed for about seven days and only surfaced on 2026-06-17 when a routine cross-chain transfer failed on insufficient escrow; Axelar disclosed it on 2026-06-19. A residual of roughly $642K–$770K was left unmoved in the attacker's Axelar wallet (the figure varies by source and snapshot).
OAK Techniques observed
OAK-T10.002 (Message-Verification Bypass — primary, confirmed mechanism. The Secret-side contract was a fork of the standard CW20-ICS20 module, adapted from an escrow model to a mint model for the Axelar integration, with two validation calls left commented out in do_ibc_packet_receive: parse_voucher_denom (which would validate the denom's <port>/<channel> trace against the packet's real source channel) and reduce_channel_balance (which would cap any release to what that channel had actually escrowed). The contract asked only whether a denom was on its allow-list, not whether the packet had arrived over an authorised channel. Because opening an IBC channel is permissionless, the attacker stood up a single-validator chain, opened a channel straight to the bridge contract, and self-relayed forged deposit packets carrying bare allow-listed denominations. The contract could not distinguish those forged deposits from real Axelar-channel deposits and minted unbacked sa* tokens, which were then redeemed over the genuine Axelar channel to release the real backing. See techniques/T10.002-message-verification-bypass.md). OAK-T11.013 (Legacy-Version Maintenance Attack Surface — the missing checks date to the contract's initial 2023 deployment (repo commit 2023-01-15; mainnet 2023-03-30) and were carried forward unchanged through a 2026-03-05 migration that updated the bytecode for new features without restoring the dropped validation). The downstream "release without matching lock" is the canonical T10.002 indicator rather than a separate technique. The cross-chain laundering path (Axelar → Osmosis → Ethereum, swap to WETH on CoW Protocol, then split to KuCoin / ChangeNow / HitBTC deposits) is OAK-T7.003 and OAK-T7.002.
Attribution
pseudonymous. No named individual or group. On-chain identifiers only: Secret secret154pdez8zazqh26wyuyu70nqraal3hkvf2f03vm, the Axelar/Osmosis hop wallet axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8, and the Ethereum consolidation wallet 0x6c2eAB82bA2897A6E99FB6Af018020dA15123976. KYC exchange deposits (KuCoin) create a potential identification path, but nothing is public. The exploit executed 2026-06-10; the Common Prefix technical breakdown is the primary source for the function names, channel IDs and per-asset figures.
Key teaching point
A bridge that mints on message receipt must verify the packet's source channel and the escrow balance, not just that the denomination is recognised. Secret Network's fork dropped exactly those two checks, so a forged packet over an attacker-opened channel was accepted as a real deposit. Two failures compounded. First, forking a standard module and adapting escrow-to-mint logic without carrying its validation forward, then migrating that code in March 2026 without restoring the checks, is the legacy-maintenance trap (T11.013): the vulnerability shipped in 2023 and survived a later upgrade. Second, the loss stayed hidden for a week because Secret encrypts balances by default, so the missing collateral was not visible on public explorers the way a drained Ethereum pool would be, and no monitoring or pause mechanism fired. The load-bearing controls are a runtime invariant that every mint reconciles to a confirmed source-side escrow, source-channel validation on every inbound packet, and value-conservation monitoring that works on encrypted balances rather than relying on explorer visibility. Secret's own note that no external audit was requested for the Axelar integration is the pre-event gap.

Summary

Secret Network is a Cosmos-ecosystem chain with encrypted (SNIP-20) balances by default, connected to the wider IBC network. Its integration with Axelar used a Secret-side contract that minted Secret-wrapped (sa*) tokens against assets escrowed on the Axelar side. That contract was a fork of the standard CW20-ICS20 IBC module, modified from an escrow model to a mint model.

On 2026-06-10, an attacker exploited two validation calls that had been commented out of the contract's packet-receive path. The contract verified that an incoming denomination was on its allow-list, but not that the packet had arrived over an authorised channel, and not that the releasing channel held enough escrow. Because IBC channel opening is permissionless, the attacker ran a single-validator chain (ibc-dev-allowlist-denom-1), opened a light client, connection and channel directly to the bridge contract, and self-relayed forged deposit packets carrying bare allow-listed denominations. The contract minted unbacked sa* tokens up to roughly the full circulating supply per asset, then the attacker redeemed those balances over the legitimate Axelar route so the real escrow released the backing assets.

The drain moved about $4.67M out through Axelar to Osmosis and on to Ethereum, where it was swapped to roughly 2,350 ETH on CoW Protocol and split across fresh wallets into exchange deposits. Because Secret's balances are encrypted, nothing looked wrong on public explorers. The incident was recognised only on 2026-06-17, when a legitimate cross-chain withdrawal bounced on insufficient escrow. Axelar disclosed the event on 2026-06-19, stated that neither Axelar nor IBC itself was compromised, and disabled the Secret connections; the vulnerable contract was Secret-side and not built or maintained by Axelar.

Timeline (UTC)

When Event OAK ref
2023-01-15 / 2023-03-30 Forked CW20-ICS20 bridge contract written and deployed to Secret mainnet with parse_voucher_denom and reduce_channel_balance commented out (standing T10.002 surface)
2026-03-05 Contract migration updates the bytecode for new features but carries the missing checks forward T11.013
2026-06-10 06:50–19:05 Attacker stands up a single-validator chain and opens a light client, connection and channel directly to the bridge contract T10.002 setup
2026-06-10 19:14–19:20 Attacker self-relays forged deposit packets with bare allow-listed denoms; contract mints unbacked sa* tokens T10.002 execution
2026-06-10 19:33–19:36 Attacker redeems the minted sa* over the real Axelar channel; escrow releases ~$4.67M of backing assets T10.002 extraction
2026-06-10 19:38–20:15 Funds bridged Axelar → Osmosis → Ethereum, swapped to ~2,350 ETH on CoW Protocol T7.003
2026-06-10 onward ETH split into ~30 transfers, deposited to KuCoin / ChangeNow / HitBTC; residual ~$642K–$770K left on Axelar T7.002
2026-06-17 15:39 A legitimate cross-chain transfer fails on insufficient escrow, revealing the drain (detection)
2026-06-19 Axelar discloses, disables Secret connections, contacts exchanges and law enforcement; declines to pursue a freeze of the residual (operator response)

What defenders observed

  • Pre-event (validation dropped in a fork, then carried through a migration). The exposure was two commented-out checks in a forked module, preserved across the 2026-03-05 migration. Auditing a fork against its upstream, and re-auditing on every migration, is the pre-event control (T11.013). Secret publicly noted no external audit was requested for the Axelar integration.
  • At-event (mint without authorised source deposit). The direct signature is a mint that does not reconcile to a confirmed, correctly-channelled source escrow. A runtime invariant tying every sa* mint to a real Axelar-channel deposit, and rejecting packets from unrecognised channels, is the highest-leverage control for this class.
  • At-event (permissionless channel to a minting contract). The attacker opened a channel straight to the bridge and self-relayed. A minting contract should pin the specific authorised channel/port and refuse deposits arriving over any other, rather than trusting an allow-list of denominations alone.
  • Detection (encrypted balances hid the loss for a week). Secret's default balance encryption meant the missing collateral was not visible on explorers, and no monitoring or pause fired. Value-conservation monitoring that operates on the protocol's own encrypted accounting, independent of public explorer views, is the detection control. This is the same detection lesson as examples/2026-06-namada-masp-ibc-transfer-logic-shielded-drain.md, where shielded-pool opacity and a stale indexer also masked an IBC-boundary drain in the same month.

Public references

Discussion

Secret Network is a clean addition to OAK's T10.002 family because it isolates a specific sub-shape: a bridge that mints on packet receipt while verifying only the denomination, not the channel the packet arrived on or the escrow behind it. It sits next to Syscoin (proof-parsing ambiguity), Nomad (trusted root initialised to zero) and Wormhole (missing guardian-account validation) in the same class, contract-side message verification admitting a message it should reject, here in a Cosmos IBC mint-on-receipt form. The IBC detail that makes it worth preserving is that channel opening is permissionless, so the attacker could deliver forged packets to the contract directly; a minting contract that pins its authorised channel would have rejected them.

The two properties that give the case durable teaching value are the legacy carry and the detection delay. The dropped checks shipped in 2023 and passed through a 2026 migration untouched, which is why T11.013 is co-primary rather than incidental: the same code that failed had been "maintained" without being re-audited against the checks it dropped. And because Secret encrypts balances by default, the drain was invisible on the layer most teams watch, so recognition came from an unrelated failed withdrawal a week later. Contributors writing future bridge examples should record both the mint-without-authorised-deposit invariant and the point that privacy-preserving accounting needs its own value-conservation monitoring, because explorer-based detection does not apply. The same-month Namada MASP drain is the sibling case for the detection lesson.

Techniques demonstrated (4)