ZetaChain Cross-Chain — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for ZetaChain Cross-Chain, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 6
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 6 closed, publicly disclosed ZetaChain Cross-Chain 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 EVM-Solidity, Solana-Rust, Move. 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 Cross-Chain
- Bridge exploit findings disclosed against ZetaChain Cross-Chain
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
ZetaChain Cross-Chain: Insufficient Transaction Broadcast Timeout in EVM Chains
ZetaChain's EVM transaction signer hardcodes a 1-second context timeout for broadcasting signatures to connected EVM chains. On higher-latency networks such as Arbitrum, the initial SendTransaction call can time out while the transaction is still propagating, and the subsequent retry with the same nonce then fails with "nonce too low." The result is dropped outbound tracker postings and state inconsistency between ZetaChain and the EVM chain, which the reporter notes would require a hard fork to repair. The protocol accepted the finding and fixed it by introducing configurable broadcastTimeout/broadcastRetries constants (PR zeta-chain/node#3850).
ZetaChain Cross-Chain: Malicious observer can block messages added through the inbound tracker
ZetaChain's Zetaclient node permanently stops processing Solana inbound cross-chain transactions after a malicious observer submits a MsgAddInboundTracker whose tx hash exceeds 64 bytes. When the inbound tracker task parses the malformed signature via MustSignatureFromBase58, it panics, and because the deferred stop-state setter runs even on panic, the task never restarts until the whole node process is manually restarted. A malicious observer can re-crash the node immediately after restart, so deposits routed through the inbound tracker remain stuck indefinitely with no mint or refund, violating the byzantine-fault-tolerance expectations of the observer set.
ZetaChain Cross-Chain: Malicious observer can drain Solana bridge by adding failed deposit transaction to inbound tracker
The ZetaChain Solana bridge's inbound observer processes Solana transactions without verifying that the transaction actually succeeded. Because the deposit/Gateway instruction is decoded as if it had succeeded regardless of whether the program reverted, a single malicious or negligent observer can hand-add a failing transaction to the inbound CCTX tracker, causing honest validators to vote and mint unbacked ZRC20 SOL on ZetaChain. The attacker then withdraws the minted ZRC20, receiving real SOL lamports and draining the bridge's locked balance. This breaks the bridge's BFT byzantine-tolerance assumption, since it only takes one compromised observer to forge a deposit for any amount.
ZetaChain Cross-Chain: SUI receiver lacks validation
In ZetaChain's cross-chain node, the SUI withdrawal receiver is encoded into a hex string on the source side (node/pkg/chains/chain.go:95) without any length or validity check. An attacker can therefore call GatewayZEVM::withdraw() with a malformed receiver address, such as a 33-byte value instead of the expected 32 bytes. The encoded transaction reaches the zetaclient SUI signer, whose buildWithdrawTx() errors out and never increments the nonce, permanently stalling all subsequent SUI withdrawals and exposing node operators to slashing and lost rewards. The protocol team fixed it in node PR 3945 by validating the receiver and broadcasting a cancel transaction when it is invalid.
ZetaChain Cross-Chain: Outbound CCTXs to external chains are not properly validated, preventing subsequent outbounds to the external chain from being processed
ZetaChain's outbound-parameter validation for ZRC20 withdrawals only covers EVM chains and Bitcoin; the Solana, SUI, and TON zetaclients have no equivalent checks. Because each of those integrations errors out on certain valid-but-unprocessable outbound CCTXs (bad execute-message payloads, unsupported coin types, invalid receiver addresses, workchain=0 mismatch, or zero-amount withdrawals) and the signers fail to send a fallback to increment the nonce, the stuck nonce permanently blocks every subsequent outbound CCTX to that chain. The finding was acknowledged but not fixed at disclosure time.
ZetaChain Cross-Chain: EVM outbound transaction gas limit can be set lower than the intrinsic gas limit, which prevents sending the transaction and blocks all other outbound transactions to this chain
A recent change to ZetaChain's zetaclient signer removed the lower-bound check on the gas limit applied to outbound EVM transactions. Because only a maximum (and a fixed 21k special case) is now enforced, an attacker can craft an outbound CCTX with a very low gas limit such as 1337. When broadcasting to Ethereum, the RPC rejects the transaction with an intrinsic-gas error; since the TSS nonce is never incremented, the CCTX sticks in the outbound queue and all subsequent outbound transactions to that chain are permanently blocked (a non-recoverable DoS). The protocol fixed it by restoring a 100k floor in PR #3848.