Axelar Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Axelar Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Axelar Network reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, across Other, EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Axelar Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Axelar Network: Bridge requests to remote chains where interchain tokens are not deployed can result in DoS attacks
Axelar's Interchain Token Service tracks per-chain token balances in its ITSHub state. The `update_token_balance` function silently returns without recording anything when the destination chain's balance entry is `None`, i.e. when the interchain token has not yet been deployed to that chain, instead of reverting the transfer. Because deployment of canonical interchain tokens is permissionless, an attacker can front-run a deployment transaction with a transfer into a chain where the token is absent, so the transfer is processed while the tracked balance remains uninitialized and later becomes 0 after the deploy step initializes it. This leaves a discrepancy between the ledgered ITSHub balance and the tokens actually bridged to the destination chain. The attacker can then exploit that mismatch to drain the tracked balance through a return transfer, causing later legitimate bridge transfers to fail due to insufficient recorded balance, a denial-of-service on the bridge.
Axelar Network: Can block bridge or limit the bridgeable amount by initializing the ITSHub balance of the original chain
Axelar's interchain-token-service ITSHub tracks per-chain token balances only for chains that are remotely deployed, leaving the original (home) chain untracked. A missing validation in InterchainTokenFactory.deployRemoteInterchainToken and deployRemoteCanonicalInterchainToken lets a caller request a remote deployment whose destination chain equals the token's own original chain, which forces ITSHub to initialize that original chain's balance to zero and keeps it tracked despite the deployment failing on-chain. Because outbound transfers decrement this balance, the zeroed original-chain balance underflows and bricks all outbound bridging for that token, or caps total bridgeable volume at the sum of other chains' balances. The impact is most severe for canonical interchain tokens, whose tokenId derives purely from the original token address, so any caller can permanently render a canonical token unusable with Axelar's bridge without Operator or FlowLimiter permissions.