ZetaChain’s Bug Was Reported by a White Hat, Dismissed as “Expected,” and Later Fueled a $334K Exploit
ZetaChain’s Bug Was Reported by a White Hat, Dismissed as “Expected,” and Later Fueled a $334K Exploit
In late April 2026, cross-chain infrastructure once again proved how small design assumptions can compound into outsized risk. ZetaChain confirmed that an attacker drained roughly $334,000 from protocol-controlled wallets through a chained set of weaknesses spanning message initiation, destination-chain execution rules, and long-lived ERC-20 allowances. User funds were not impacted, but the incident is still a sharp reminder: in cross-chain systems, “low-risk” components rarely stay low-risk when they interact.
What makes this case especially instructive is the process failure behind the technical failure. ZetaChain acknowledged that the core issue had been reported earlier through its bug bounty channel, yet was initially treated as intended behavior rather than something requiring mitigation or tighter constraints. Coverage of the disclosure and post-incident details can be found in reporting such as Cointelegraph’s recap of the dismissed report and subsequent exploit: ZetaChain dismissed a bug report that could have prevented the exploit.
Below is an operator-friendly breakdown of what happened, why the exploit path worked, what ZetaChain changed, and what builders and users should take away in 2026—when cross-chain activity is broader than ever and attacker playbooks are increasingly “multi-vector by default.”
Incident snapshot: cross-chain design debt comes due
The attacker’s actions ultimately resulted in 9 transactions spanning Ethereum, Arbitrum, Base, and BNB Smart Chain, with stolen assets originating from wallets controlled by ZetaChain rather than end users. ZetaChain paused cross-chain operations as the issue was contained; the initial halt was widely reported when the incident first surfaced publicly (see: The Block’s report on the pause and mitigation).
While the dollar amount was not “bridge-mega-hack” scale, the pattern is what matters: a cross-chain gateway that can be influenced to produce protocol-signed calls on external chains is a high-leverage target, even when the immediate victim set is limited.
The uncomfortable lesson: “expected behavior” can still be exploitable behavior
Bug bounty programs are meant to convert adversarial curiosity into defensive improvement—but only if triage is built to recognize composability risk.
ZetaChain previously launched its bounty program in partnership with Immunefi (background: ZetaChain’s bug bounty announcement). Yet this incident highlights a recurring industry challenge: a report can be “correct” even if each individual component appears non-critical in isolation. Immunefi itself emphasizes that real-world impact and scope definitions matter (see: Immunefi’s guidance on program rules and impact).
For cross-chain protocols, the bar should be higher: if a feature enables any path to “the protocol can be tricked into signing something it shouldn’t,” then it deserves defense-in-depth—even if the feature is technically functioning as designed.
How three “small” issues chained into one big exploit
A detailed technical walkthrough of the call flow and contract behavior was published by independent researchers; one of the clearest step-by-step analyses is: ZetaChain Gateway hack analysis.
From a security design perspective, the exploit chain can be summarized as three links:
1) Permissionless cross-chain instruction initiation at the gateway layer
One core issue was that a gateway-side pathway could be invoked in a way that allowed an attacker to inject cross-chain intent (i.e., “send this message/call to the destination chain”) without the system enforcing the expected trust boundary for who is allowed to originate such instructions.
In cross-chain systems, who gets to emit a “this should be executed remotely” signal is the first and most important line of defense.
2) Destination execution rules that were too permissive (and too reliant on a narrow deny-list)
On the receiving side, the execution pathway allowed calls that were effectively “arbitrary” in nature, with restrictions that were not broad enough to block dangerous token operations. A blacklist that only blocks a couple of selectors is rarely sufficient when the EVM surface area is enormous—and when attackers only need one allowed primitive (like transferFrom) to monetize.
This is a common failure mode: deny-lists age poorly in adversarial environments.
3) Stale ERC-20 allowances turned “execution” into “asset movement”
The final link was operational rather than purely code: some wallets maintained unlimited approvals (or otherwise excessive allowances) to the gateway contract and didn’t clear them after they were no longer required.
In ERC-20, an allowance is effectively a standing permission. Once a contract gains the ability to make a token call as itself, any leftover allowance becomes a loaded weapon. For context on how approvals work at the standard level, see: OpenZeppelin’s ERC-20 documentation.
Research has also shown how widespread unlimited approvals are—and why they create systemic risk—well beyond any single protocol (see: “Penny Wise and Pound Foolish” approval-risk study).
Attacker tradecraft: not opportunistic, but staged
ZetaChain described the exploit as showing clear signs of planning, including:
- Pre-funding via Tornado Cash days in advance
- Deploying a dedicated “drainer” contract
- Running an address poisoning campaign
Address poisoning deserves special attention because it’s increasingly blended into broader exploit operations—not only as a retail scam, but also as a way to create confusion during incident response. If you want a rigorous overview of the technique and why it works so often, Carnegie Mellon researchers maintain a dedicated resource here: Blockchain address poisoning overview.
What ZetaChain changed: removing footguns, not just patching bugs
Post-incident fixes matter most when they reduce class risk rather than only blocking one observed payload. Based on ZetaChain’s disclosed remediation direction (as summarized in public reporting and technical analyses), the key changes include:
- Rolling out patches to mainnet infrastructure to close the exploited pathway.
- Permanently disabling the arbitrary-call capability that made the “execute whatever calldata the protocol signs” outcome possible.
- Replacing unlimited approval patterns in deposit flows with exact-amount approvals, so a single approval can’t silently remain usable months later.
The most important theme is the shift from “powerful but dangerous generality” toward “narrow, verifiable intent.” Cross-chain protocols that want to scale safely in 2026 will increasingly need to default to allow-listed targets, typed messages, and capability-limited execution.
Builder takeaways: cross-chain security in 2026 is about composition, not components
Even outside ZetaChain, cross-chain systems keep getting attacked because they sit at the intersection of:
- complex state machines,
- distributed signing/validation,
- and highly monetizable token interfaces.
Industry loss reports continue to show that exploit severity remains high and tail-risk events dominate outcomes (see one example of aggregated industry tracking in: Immunefi’s “Crypto Losses in Q1 2025” report (PDF)).
If you are designing or integrating cross-chain messaging, consider these practical guardrails:
- Make message origination explicit and authenticated: “Anyone can request a cross-chain call” should never be equivalent to “the protocol will sign and execute it.”
- Avoid deny-lists for execution sinks: prefer allow-lists and minimal interfaces.
- Treat allowances as part of your threat model: treasury / operator wallets should have strict approval policies, monitoring, and periodic cleanup.
- Plan for emergency coordination: incident response networks like SEAL 911 exist because minutes matter when signatures and cross-chain execution are involved.
User checklist: what to do after any cross-chain incident (even if “users weren’t affected”)
Even when a protocol says user funds were not impacted, it’s rational to take 10 minutes to reduce your personal blast radius—especially if you’ve ever interacted with the affected gateway contracts.
1) Revoke allowances you don’t actively need
Two reliable options:
- Use an approval management tool such as Revoke.cash token approval guide
- Or use a block explorer’s built-in checker like Etherscan’s Token Approval Checker
2) Defend against address poisoning in daily behavior
- Don’t copy recipients from transaction history.
- Use address books / trusted contacts where possible.
- Verify more than the first/last few characters—poisoning attacks are designed to match what wallet UIs truncate.
3) Use hardware-based address verification for high-value transfers
A hardware wallet can’t stop a smart contract bug on a protocol you don’t control—but it can reduce the chance you personally authorize the wrong recipient during an address poisoning or clipboard-manipulation scenario.
This is where OneKey fits naturally: by keeping signing isolated and emphasizing on-device verification, it helps make “what you sign” closer to “what you intend”—especially during stressful moments when attackers try to exploit confusion.
Closing thoughts
ZetaChain’s exploit is a compact case study in modern crypto security reality:
- a previously reported issue,
- dismissed due to a “by design” assumption,
- combined with permissive execution and leftover approvals,
- executed by an attacker who prepared funding, tooling, and social-layer noise in advance.
If 2025–2026 has taught the industry anything, it’s that cross-chain systems must be engineered for adversarial composition. The safest feature is the one you cannot accidentally turn into a signing oracle—even when everything is “working as expected.”
