Skip to main content
• 6 min read

ZetaChain GatewayEVM Arbitrary Call
Exploit Drains $333K from Team Wallets Across Four Chains

ZetaChain suffered a targeted GatewayEVM exploit after an arbitrary-call path and stale ERC-20 approvals let an attacker route transferFrom calls through the protocol's TSS-signed cross-chain execution flow. ZetaChain said no user funds were affected, while three team-controlled wallets lost about $333,868 across Ethereum, Arbitrum, Base, and BSC.

AUTOSEC.DEVAUTOSEC.DEV
ZetaChain GatewayEVM Arbitrary Call Exploit Drains $333K from Team Wallets Across Four Chains
  • Incident Date: April 26-27, 2026
  • Target: ZetaChain GatewayEVM / GatewayZEVM cross-chain execution pipeline
  • Target Overview: ZetaChain is a universal Layer 1 network designed to support omnichain applications across EVM chains and non-EVM networks. The affected path connected ZetaChain-side cross-chain calls with destination-chain execution through the GatewayEVM contract and the protocol's TSS signer.
  • Total Loss: ~$333,868, mainly USDC and USDT. ZetaChain stated that the impacted wallets were team-controlled and that user funds were not affected.
  • Attack Vector: Public arbitrary cross-chain call path / insufficient destination-call filtering / stale unlimited ERC-20 approvals

Incident Review & Technical Details​

1. Attack Path​

  1. Preparation and Obfuscation: Public reporting and ZetaChain's post-mortem indicate that the attacker prepared in advance, including Tornado Cash funding and wallet address spoofing. This was not a simple opportunistic drain; the attacker appeared to know which wallets had useful token balances and approvals.
  2. Source-Side Arbitrary Call Creation: The attacker deployed a contract on ZetaChain and invoked GatewayZEVM.call() with an arbitrary-call flag. The call selected an ERC-20 token contract as the remote destination and encoded transferFrom(victim, attacker, amount) as the payload.
  3. Cross-Chain Message Accepted as Valid: ZetaChain observers processed the emitted call event as a legitimate cross-chain transaction. Because the arbitrary-call mode caused the destination messageContext.sender to be treated as empty, the destination-side gateway routed execution into its arbitrary-call branch.
  4. TSS-Signed Destination Execution: On the destination EVM chains, GatewayEVM.execute() could only be called by the protocol's TSS role. In this attack, that check did not stop the exploit because the TSS legitimately signed and broadcast the attacker-influenced cross-chain message.
  5. Selector Filtering Bypass: The arbitrary execution path blocked only narrow gateway callback selectors such as onCall and onRevert. It did not block ERC-20 selectors such as transferFrom, approve, or transfer. As a result, token contracts accepted the gateway-originated transferFrom calls.
  6. Allowance Pivot: The affected wallets had previously granted allowances to the gateway, reportedly through prior GatewayEVM.deposit() flows. Once the gateway was tricked into calling token contracts with attacker-supplied calldata, those stale approvals became the actual drain primitive.
  7. Multi-Chain Drain and Swap: The attack was repeated across Ethereum, Arbitrum, Base, and BSC. Reports describe nine drain transactions against three team-controlled wallets, followed by swaps of stolen stablecoins into ETH and consolidation to an attacker-controlled wallet.

2. Impact Scope​

  • Direct Losses: ZetaChain's post-mortem reported approximately $333,868 in losses, mainly USDC and USDT. SolidityScan's transaction-level breakdown puts the gross drain in the same range, with a smaller final ETH amount after slippage and bridging costs.
  • Affected Wallets: Three wallets were impacted, all described by ZetaChain as team-controlled. Public statements said no external user funds were lost.
  • Affected Networks: Ethereum, Arbitrum, Base, and BSC were involved in the drain path.
  • Operations Impact: ZetaChain paused mainnet cross-chain transactions while investigating and preparing a patch. BeInCrypto reported that the pause was visible on ZetaChain's status page as a precautionary response.
  • Unaffected Scope: ZetaChain stated that cross-chain ZETA transfers were not affected.

3. Root Cause​

The incident is best understood as a chained control failure rather than one isolated line of vulnerable code:

  • Public Reachability of Arbitrary Calls: A source-side call path allowed externally supplied cross-chain instructions with insufficient restrictions on destination and calldata.
  • Destination Gateway as an Authority Amplifier: The destination call was executed by the protocol's trusted gateway/TSS flow. Once the message was accepted, token contracts saw the gateway as the caller.
  • Deny-List Filtering Was Too Narrow: Blocking only known gateway callback selectors left common ERC-20 operations available to attacker-controlled calldata.
  • Long-Lived Approvals Created Blast Radius: Unlimited or stale ERC-20 approvals meant the gateway already had token-spending authority from the affected wallets.

Any one of these controls could have broken the exploit chain. Together, they turned a cross-chain arbitrary-call feature into a multi-chain token allowance drain.

4. Mitigation and Response​

ZetaChain stated that it blocked the attack vector, deployed a mainnet patch, and kept cross-chain transaction functionality disabled pending further upgrades and review. Public reports also noted that users who had previously interacted with the gateway contracts were advised to revoke outstanding ERC-20 allowances.

Recommended remediation for protocols with similar gateway designs:

  • Remove externally reachable arbitrary-call modes from cross-chain message paths, or restrict them to tightly governed protocol-internal callers.
  • Bind source-chain caller identity to destination execution context so destination contracts can verify the original sender.
  • Replace broad destination.call(data) behavior with explicit allow-listed interfaces and selectors.
  • Block token-control selectors such as transferFrom, approve, permit, and transfer in any emergency compatibility layer.
  • Avoid indefinite approvals from treasury, operator, and team wallets to bridge or gateway contracts.
  • Monitor for cross-chain executions where the destination is a token contract and calldata begins with high-risk ERC-20 selectors.
  • Treat "feature works as designed" bug bounty reports as potentially valid when multiple weak assumptions can be chained.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

Cross-chain incidents often emerge from the interaction between correct-looking modules: relayers, gateway contracts, token approvals, signer roles, and operational wallets. AUTOSEC.DEV helps teams test those system-level assumptions before attackers do.

  1. Cross-Chain Gateway Security Review: We review message construction, source identity binding, destination execution, selector filtering, replay protection, pauser roles, and TSS/relayer trust boundaries.
  2. Smart Contract Logic Audit: We identify unsafe external-call patterns, broken access control assumptions, approval-dependent drains, and feature combinations that become dangerous when chained.
  3. Treasury & Operator Wallet Risk Review: We map privileged wallet approvals, stale allowances, signer exposure, and high-impact operational flows across chains.
  4. End-to-End Incident Response (IR): In an emergency, AUTOSEC.DEV provides standardized SOPs, exploit-path analysis, allowance containment, and coordination support to help teams reduce loss windows quickly.

Service Content​

Reference​

https://x.com/ZetaChain/status/2048854107633631356?s=20