19 Mar 2025 7 min read

Halting Cross-chain: Axelar Network Vulnerability Disclosure

Disclaimer: This article discusses a vulnerability disclosure related to Axelar Network. Marco Nunes is publishing this information as part of his company’s security research work and is not affiliated with, endorsed by, or sponsored by Axelar Network. This research was conducted independently and facilitated through the Immunefi bug bounty platform. A bug bounty reward was received for the responsible disclosure of this vulnerability.

Important Update (March 20, 2025): This article provides a vulnerability disclosure, describing a past exploit path within the Axelar Network. Axelar Network has since confirmed that the Chain Maintainer auto-deregistration mechanism, which was central to triggering this vulnerability, has been disabled via governance proposal 256 (https://axelarscan.io/proposal/256). This vulnerability is no longer exploitable since then. The article below is a retrospective analysis of the vulnerability and the disclosure process.

➤ Reported on: May 7, 2024
➤ Reported severity: Critical
➤ Accepted severity: Critical
➤ Mediation rounds: 4
➤ Reward: $50,000 (USDC)

Enter Axelar

Axelar relies on a set of validators that participate in block creation, multi-party cryptography protocols, and voting. All of this happens in the Axelar chain (axelar-core), an application built on Cosmos SDK.

The key role to understand this vulnerability is the validators’ responsibility as “Chain Maintainers”: they vote on External Chain Events.

Besides participating in Tendermint consensus, validators register as maintainers for the chains they choose to support, voting regularly on these chains’ External Chain Events. Axelar naturally enforces specific rules to guarantee validator availability and integrity:

Validators who consistently miss votes beyond a defined threshold within a specific block window are penalized by losing rewards and deregistered for safety.
A chain requires a minimum validator quorum (0.6 from the total consensus weight of all validators in the system) to enable cross-chain messages from a given EVM chain; below this threshold, cross-chain operations from that chain are halted.

Validators also run a companion off-chain software called vald to timely cast their votes on External Chain Events.

For simplicity, we’ll focus specifically on the transaction logs emitted by the AxelarGateway contract on EVM chains after executing callContract successfully:

    event ContractCall(
        address indexed sender,
        string destinationChain,
        string destinationContractAddress,
        bytes32 indexed payloadHash,
        bytes payload
    );

// Source: https://github.com/axelarnetwork/axelar-cgp-solidity/blob/83012e6f6fb721d7ffaaec9426fdac3c02fced2e/contracts/interfaces/IAxelarGateway.sol#L29

When users invoke callContract, this triggers the emission of an event. Validators subsequently vote on the polls generated after the Axelar chain receives the relevant transaction ID(s) through the ConfirmGatewayTxs message:

EVM Chain:
1. User calls callContract(...) on AxelarGateway contract
2. AxelarGateway emits the ContractCall event
Axelar Chain (Cosmos):
1. ConfirmGatewayTxs message is processed with the relevant txids
2. Polls are generated based on these txids
3. vald, constantly running, is used by Validators (as Chain Maintainers) to vote on the polls automatically via Tendermint’s RPC

With this simplified background, let’s explore the vulnerability.

The Primitive

I discovered that validators can be forced to predictably skip voting on transactions containing an excessive number of logs due to a default Tendermint configuration limiting the RPC request body size to approximately 1 MB (max_body_bytes). Typically, skipping votes is safer than potentially casting incorrect votes.

# Maximum size of request body, in bytes
max_body_bytes = 1000000

# Source: https://github.com/axelarnetwork/axelarate-community/blob/95ac438ea31e954acf0bdd556b43e3933be994ab/configuration/config.toml#L146

This configuration is the seldom changed default on Tendermint and the one validators end up with after following Axelar’s official setup instructions. Notably, as this limit isn’t enforced by consensus, validators could silently diverge in voting behavior if their settings differ, which may lead to dangerous behavior—an intriguing point, though a separate matter.

The critical point is: validators reliably skip voting whenever the logs data is large enough to make the subsequent RPC request to Axelar Chain exceeds this 1 MB limit. This undocumented limit could itself be considered a vulnerability in certain scenarios, but it wouldn’t be sufficient to justify a Critical/High severity impact reward on its own. Instead, it serves as the trigger mechanism for the core vulnerability.

The Vulnerability

The primitive alone is seemingly harmless. That’s because the concerning vulnerability I encountered is that Axelar lacks a minimum voting quorum requirement before penalizing and deregistering validators for missed votes. This means that if we can consistently force Chain Maintainers to miss voting above the threshold, we can have them deregistered as Chain Maintainers and their rewards forfeited. And, given this affects virtually all Chain Maintainers in the network, we can effectively halt Axelar’s EVM cross-chain operations, affecting millions in locked cross-chain value.

Missing votes are marked and penalized:

[... SNIP ...]
// Penalize voters who failed to vote
for _, voter := range poll.GetVoters() {
    hasVoted := poll.HasVoted(voter)
    if maintainerState, ok := v.nexus.GetChainMaintainerState(ctx, chain, voter); ok {
        maintainerState.MarkMissingVote(!hasVoted)
        funcs.MustNoErr(v.nexus.SetChainMaintainerState(ctx, maintainerState))

        v.keeper.Logger(ctx).Debug(fmt.Sprintf("marked voter %s behaviour", voter.String()),
            "voter", voter.String(),
            "missing_vote", !hasVoted,
            "poll", poll.GetID().String(),
        )
    }

    if !hasVoted {
        rewardPool.ClearRewards(voter)
        v.keeper.Logger(ctx).Debug(fmt.Sprintf("penalized voter %s due to timeout", voter.String()),
            "voter", voter.String(),
            "poll", poll.GetID().String())
    }
}
[... SNIP ...]

// Source: https://github.com/axelarnetwork/axelar-core/blob/c7afbd0703a1f9ee1af415490ba2e931fc2bc1f7/x/evm/keeper/vote_handler.go#L64C1-L84C3

Missing vote threshold for Chain Maintainer removal:

ChainMaintainerMissingVoteThreshold:   utils.NewThreshold(20, 100),
[... SNIP ...]
ChainMaintainerCheckWindow:            500,
        
// Source: https://github.com/axelarnetwork/axelar-core/blob/c7afbd0703a1f9ee1af415490ba2e931fc2bc1f7/x/nexus/types/params.go#L38C2-L40C46

This default had remained unchanged and meant that validators could miss up to 100 polls within the 500-poll check window without being removed. When they missed the 101st poll within the check window, they were removed as Chain Maintainers.

Chain Maintainer removal:

[... SNIP ...]
if hasProxyActive &&
    utils.NewThreshold(int64(missingVoteCount), int64(window)).LTE(params.ChainMaintainerMissingVoteThreshold) &&
    utils.NewThreshold(int64(incorrectVoteCount), int64(window)).LTE(params.ChainMaintainerIncorrectVoteThreshold) {
    continue
}

rewardPool.ClearRewards(maintainerState.GetAddress())
if err := n.RemoveChainMaintainer(ctx, chain, maintainerState.GetAddress()); err != nil {
    return err
}
[... SNIP ...]

// Source: https://github.com/axelarnetwork/axelar-core/blob/c7afbd0703a1f9ee1af415490ba2e931fc2bc1f7/x/nexus/abci.go#L47C1-L56C5

This vulnerability could potentially be targeted in many different ways, but I needed to use the primitive to prove it’s exploitable. Otherwise, it wouldn’t qualify as a valid bounty submission.

The Exploit

I’ll demonstrate just the exploit path I chose for the PoC. Obviously, there are other approaches, such as using different event types or creating a different combination of logs per (up to 10) txids. The only requirement is that the resulting data payload for the vald RPC call must be above the set RPC request limit.

So, with the vulnerability and our primitive as a way to trigger the vulnerability, this is the attack sequence:

EVM chain: Attacker creates 2 “malicious” transactions that make AxelarGateway store 2000 ContractCall logs each
Axelar Chain: Attacker sends the ConfirmGatewayTxs message on Axelar Chain with the malicious txids as parameters; this triggers the initialization of two polls to be voted by Chain Maintainers
Off-chain: vald detects that the polls have been initialized on Axelar Chain for two txids, fetches the stored logs data from their EVM RPC endpoint, attempts to vote... Fails due to the RPC request limit (max_body_bytes)
Attack completion: Attacker repeats step 2, which triggers step 3, enough times within a block interval window (missing vote threshold) to trigger massive Chain Maintainer deregistration for the targeted EVM chain due to missing votes

For the malicious logs preparation in the PoC, I used a Forge script that had to be called for each transaction: https://gist.github.com/marcotnunes/d1df2d2ac4e7226895ac973d294fc687

(Yeah, optimizooors, this can be optimized. This is just a PoC, and most costs come from storing the logs anyway)

Cost Analysis

This was valid approximately at the time of reporting and may vary in either direction. Values have been deliberately overestimated to provide a substantial safety margin in the analysis.

One-time setup cost for log creation across the most active EVM chains on Axelar at the time (Ethereum, BSC, Polygon PoS, Avalanche, Arbitrum, and Base): 4000 USD + (200 USD * 5) = 5000 USD (Fixed cost)
~66 USD to drop Chain Maintainers on Axelar Chain for all EVM chains (Moving cost)
Total initial cost (over-inflated): 5066 USD
From now on a moving cost of 11 USD on Axelar Chain fees to drop the Chain Maintainers for each chain that reaches the threshold to resume operations, indefinitely. Anyone can do it with the same the Gateway transactions IDs repeatedly and “permissionlessly” without having to recreate the costlier part of the attack.

$5066 to halt cross-chain operations from the six most active EVM chains on Axelar Chain, until the minimum quorum of re-registered Chain Maintainers is reached, only for them to be cheaply dropped again ($11 per chain) by anyone.

Impact

The main direct impact is Vulnerabilities related to validator voting manipulation on external chain events (Critical), an impact that existed at their BBP at the time.

This attack allows an attacker to systematically force the deregistration of all Chain Maintainers across multiple EVM chains, causing the system to fall below the required 60% validator quorum threshold. Without this minimum quorum, all cross-chain operations between affected chains halt. Even when validators eventually manually re-register themselves as Chain Maintainers, the attacker can cheaply trigger their deregistration again. This creates a complete blockage of cross-chain transactions that can be sustained continuously, effectively rendering the cross-chain functionality inoperable for the targeted EVM chains until emergency actions are implemented.

Severity Classification and Resolution

Initial Response: Axelar initially classified the report as “Medium” severity within 32 minutes of submission, offering a 5,000 USDC reward. Their initial assessment characterized the issue as a trade-off prioritizing safety over liveness.

The Mediation: Following the initial response, multiple rounds of mediation were conducted through Immunefi. Immunefi’s mediation team, based on the provided technical evidence and proof-of-concept, eventually confirmed the “Critical” severity classification. Axelar provided further rationale for maintaining a “Medium” classification, leading to additional mediation rounds. The “Critical” assessment was reaffirmed in each of these subsequent rounds.

Final compromise proposal: Axelar proposed a resolution with an increased reward of 20,000 USDC, while maintaining the “Medium” severity classification. This proposal was not accepted.

Resolution: After a five-month process, the issue was resolved with Axelar accepting the “Critical” severity classification and awarding the 50,000 USDC bounty.

Pre-Publication Communication

As part of my commitment to responsible disclosure, I initiated communication with Axelar prior to this public disclosure. In early January 2025, I contacted them through the Immunefi platform to inquire about the status of the vulnerability and potential remediation steps. My intention was to provide advance notice of my intention to publish. I also engaged with Immunefi to facilitate communication and confirm the timeline for disclosure. As of the publication date, I have not received confirmation from Axelar regarding the specific remediation steps taken nor details of a fix. Validators should verify their implementations.

At the time of reporting, Axelar was on Immunefi’s Legacy Responsible Publication Policy. Immunefi has confirmed that this publication is in accordance with their responsible disclosure policy.

Immunefi: Thank You For Having My Back

My heartfelt thanks goes to the mediation team for standing firm on this one. When Axelar went silent and kept shifting their arguments for months, the mediation team remained steady, consistently supporting the reality of my finding without faltering. Through four rounds of mediation and across the long silence, they didn’t hesitate to call it like they saw it.

The journey of a security researcher can be a lonely one when facing pushback on valid findings. Having a team that understands the technical details and stands as an ally in these moments makes all the difference. That’s what proper mediation should be about.