ZetaChain — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for ZetaChain, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 5
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 5 closed, publicly disclosed ZetaChain 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, Bridge exploit, across Cosmos-SDK, 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 ZetaChain
- Bridge exploit findings disclosed against ZetaChain
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
ZetaChain: ZRC20 Token Pause Check Bypass
ZetaChain's crosschain module calls into the zEVM during CCTX processing below the point where Ethermint's post-transaction hooks run. Because the fungible module's ZRC20 pause check is implemented as one of those hooks and the crosschain path calls processLogs without invoking CheckZRC20Paused, a paused token can still be withdrawn via the onCrossChainCall callback. An attacker deploys a contract that approves and withdraws the ZRC20 in its callback, then submits a VoteOnObservedInboundTx to trigger the withdrawal. This defeats the protocol's emergency pause mechanism, which is meant to halt token movement if a vulnerability is discovered.
ZetaChain: Inbound transactions submitted to the `InTxTracker` that contain multiple `ZetaSent` and `Deposited` events are not processed correctly by the observers resulting in a loss of funds
ZetaChain's observer software stops iterating over a transaction receipt's logs as soon as the first ZetaSent (or ERC-20 Deposited) event yields a valid vote message, because of a break statement in the CheckReceiptForCoinTypeZeta and CheckReceiptForCoinTypeERC20 functions. Any inbound transaction can legitimately contain multiple such events when a cross-chain onZetaMessage handler routes to multiple sends or a custody deposit loop fires repeatedly, but only the first event is voted on and forwarded to ZetaChain. When observers have already missed the transaction (why it was submitted to the InTxTracker), the additional events go unprocessed and the corresponding locked/burned Zeta or deposited ERC-20 tokens are at risk of being lost. The proposed fix is to remove the break statements so every matching event in the receipt is voted upon.
ZetaChain: `PayGasFeeInZetaAndUpdateCctx()` is prone to slippage, causing sender overpays the revert gas and lose returned funds
ZetaChain's cross-chain keeper pays outbound and revert transaction gas by swapping ZETA or an ERC20 against the system wzeta/gasZRC20 UniswapV2 pool. The flow quotes the required input with QueryUniswapV2RouterGetZetaAmountsIn and then executes the swap with an exact input amount, but never validates the quoted price against any slippage bound. If the pool briefly becomes imbalanced, the quoted gas fee is inflated, so the sender is overcharged for gas or, when the inflated fee exceeds the ZETA actually burned, the revert cctx is aborted entirely and the user loses their refunds. The sponsor confirmed the issue and the judge ruled it a medium-severity leak of value.
ZetaChain: ERC-20 deposit cctxs are refunded to the EOA instead of an intermediary contract
ZetaChain's zetaclient builds the cross-chain vote message for an inbound ERC-20 deposit by recovering the originating EOA transaction signer via the London signer and placing that address into the message's Sender field, rather than using the actual msg.sender of the ERC20Custody.deposit call. When a subsequent inbound cctx fails (for example by hitting the foreign-coin liquidity cap in the fungible module), the refund is sent back to this Sender address. If a user deposited through an intermediary contract deployed on a supported EVM chain, the refund is therefore routed to the user's EOA instead of the intermediary contract, potentially letting that EOA claim funds that belong to the contract. The confirmed fix is to emit msg.sender as an additional parameter in the Deposited event and use it to populate the Sender field of the vote message.
ZetaChain: Incorrect genesis initialization of pending nonces
ZetaChain's crosschain module initializes pending nonces to zero during genesis even when the chain the node is being reinstalled for has an existing, non-zero transaction nonce. Because the pending nonce (NonceHigh) is later compared against the assigned nonce in UpdateNonce, resets or hard forks produce a NonceMismatch error. That error blocks EVM inbound processing, inbound/outbound refunds, cross-chain messaging, TSS fund migrations, and ERC-20 whitelisting, permanently stalling those cctxs unless validators reapply a fix.