Secret Network Loses $4.67M in Axelar Cross-Chain Exploit — Undetected for Seven Days
Secret Network Loses $4.67M in Axelar Cross-Chain Exploit — Undetected for Seven Days
On June 21, 2026, researchers at Common Prefix published findings on a cross-chain bridge incident involving Secret Network and an Axelar-connected contract. The attacker allegedly exploited a flaw in a Secret-side ICS-20 bridge contract, forged “deposits,” minted unbacked tokens, and exited liquidity for an estimated $4.67 million.
What makes this event especially instructive isn’t only the loss amount—it’s the timeline: the exploit reportedly persisted for about a week before anyone noticed, and the first hard signal was not an alert, but an operational failure when a legitimate transfer could not be completed.
This post breaks down what happened, why the failure mode is common in cross-chain systems, and what both users and builders can do to reduce exposure as interoperability becomes a default in 2025–2026 crypto product design.
What reportedly happened: a clear timeline, a delayed alarm
Based on the disclosed investigation:
- June 10, 2026: the attacker began abusing a vulnerability in a Secret Network ↔ Axelar cross-chain bridge contract by fabricating inbound transfer state and minting tokens without collateral.
- June 10–17, 2026: the attacker repeatedly converted the minted assets into more liquid tokens and routed proceeds outward.
- June 17, 2026: a normal cross-chain transfer failed because the bridge’s custody/escrow account no longer had sufficient funds—surfacing the anomaly.
This “silent drain until a user hits the wall” pattern is a recurring operational risk for bridges: if monitoring focuses on uptime and message throughput (rather than economic invariants), exploits can hide in plain sight.
For readers who want a refresher on how IBC-style token transfers are typically modeled (escrow on one side, representation minted on the other), Secret Network’s documentation on IBC and ICS-20 related tooling is a good starting point.
Root cause (as described): when an escrow model turns into a minting model
The disclosed analysis attributes the core bug to a contract refactor: a shift from a custody / escrow flow to a minting flow—while removing critical checks that proved the transfer’s origin.
In plain English:
- A bridge contract receives a cross-chain message claiming, “X tokens were deposited on Chain A for user Y.”
- The destination contract must verify that message really came from the expected channel / gateway / sender.
- Only then should it mint or release assets.
According to the disclosure, the vulnerable contract removed two key functions responsible for validating the source of transfers, allowing an attacker to submit data that looked like a valid inbound transfer and trigger minting without real backing.
Even worse, the report states that the contract had been deployed since early 2023 and never underwent an external audit—a governance and process gap that is hard to justify for any contract controlling cross-chain mint authority.
For context on how serious bridge audits are expected to be at the infrastructure layer, you can review Axelar’s public audit resources at Axelar Network’s audits repository and Axelar’s own perspective in its post on security at Axelar core.
Why it went unnoticed: “no sirens” before the vault was empty
A key claim from Secret Network’s side is that Axelar’s bridge infrastructure did not trigger effective anomaly detection or an emergency pause mechanism before significant value had already left the system.
Whether the responsibility ultimately sits with the application contract, the bridge provider, or shared operations, the lesson is broader:
Cross-chain systems need economic monitoring, not just technical monitoring
Bridges are not only “message pipes.” They are financial systems with invariants:
- Minted supply vs. escrowed backing
- Daily mint limits
- Per-route exposure caps
- Abnormal redemption / swap patterns
- Spike in failed transfers (often a late-stage symptom)
In 2026, the industry is already repricing this risk. For example, after a separate bridge-driven event, Aave moved to tighten listing and risk standards—highlighting how bridge fragility can spill into DeFi money markets (CoinDesk coverage).
Where the funds went: Osmosis routing, Ethereum settlement, then CEX off-ramps
The disclosed tracing indicates a familiar laundering path:
- Assets were routed through Cosmos liquidity rails, reportedly via Osmosis, which functions as a major cross-chain DEX hub (see Osmosis documentation).
- Proceeds were then bridged to Ethereum and swapped into ETH using CoW Protocol (see CoW Protocol documentation), before being fragmented across multiple addresses.
- Some funds were reported to have reached centralized venues including KuCoin, ChangeNow, and HitBTC.
The report also claims roughly $672,000 remained in an attacker-controlled Axelar wallet at the time of publication, and that requests to freeze that address were denied—while Axelar emphasized the exploited contract was not developed or maintained by Axelar, and that Axelar’s core protocol was not compromised.
What this incident says about 2025–2026 bridge risk
Interoperability is accelerating—wallet UX is trending toward “one-click cross-chain,” and apps increasingly assume chain abstraction by default. But that convenience expands the attack surface in three ways:
- More contracts gain mint authority somewhere (and mint authority is the highest privilege in token design).
- Refactors are frequent as teams chase faster routes, lower fees, and better UX—often introducing regression risk.
- Responsibility becomes ambiguous across app teams, bridge providers, relayers, and monitoring stacks.
The result: even if a bridge network is robust, a single weak integration contract can become the failure point.
Practical takeaways
For builders: reduce “mint authority blast radius”
- Treat any cross-chain minting contract like a systemically important component: mandatory external audits, formal review gates, and continuous monitoring.
- Add circuit breakers: rate limits, per-asset caps, and automatic pause triggers tied to invariant violations.
- Monitor backing vs. minted supply on every route; alert on drift, not just on downtime.
- Avoid removing validation logic during “model changes” (escrow → mint, or vice versa) without adversarial review and regression tests.
For users: assume bridges are higher-risk than spot swaps
- Keep only what you need in bridged representations; don’t treat wrapped assets as long-term cold storage.
- After bridging, consider moving funds into self-custody and verifying the asset you received (chain, denom, contract) before interacting further.
- Prefer workflows where you can independently verify what you sign and where it goes—especially when bridging and swapping across multiple hops.
Where OneKey fits: self-custody in a cross-chain world
Bridge incidents are a reminder that “not your keys, not your coins” is only half the story—the other half is minimizing the time and value you leave inside complex smart contract routes.
A hardware wallet like OneKey helps by keeping private keys offline and making it easier to review and confirm destination addresses and transaction intent before signing—an important habit when cross-chain UX can obscure what’s happening under the hood.
In 2026’s multi-chain reality, the safest default is: bridge only when needed, verify every signature, and return to self-custody when you’re done.
