On April 28, 2026, the cross-chain gateway of ZetaChain was torn open by a truly fatal blow. The GatewayZEVM contract, originally responsible for transporting assets and forwarding messages across multiple chains, was reported to have suffered a security attack, causing cross-chain calls to no longer be driven by a trusted process, but rather be manipulated by attackers. From that day on, ZetaChain was no longer just a technical narrative of a cross-chain smart contract platform, but was forced to confront a more realistic identity — an exploited entry point for attacks.

On the same day, the security team Slow Mist provided the initial technical attribution, pointing directly to a core interface in the GatewayZEVM contract: the `call` function. This inter-chain calling entry, which should have been strictly restricted, lacked the necessary access controls and input validation, allowing any user to initiate cross-chain calls through the gateway. The attacker seized this weakness by crafting forged cross-chain events, misleading the relayer into performing operations on the target chain that should not have occurred, thus opening up the attack surface for malicious calls and fund transfers. This design flaw was seen as yet another replay of common security issues found in cross-chain protocols.

However, as technical details were quickly dissected, the most intuitive and easily questioned piece of information — how much was lost and which addresses were affected — was still without a clear answer. Research briefs and media reports repeatedly emphasized that there was currently no verified specific loss amount, attacker addresses, or affected wallet address data; this key information was marked as missing or pending verification. Thus, on April 28, the only certainty was that the security boundary of GatewayZEVM had been breached; as for how large that crack was, it remained an open question.

Cross-chain Gateway Breach: Attack Erupted on April 28

On April 28, rumors about ZetaChain first emerged in chat groups within the tech community and on security monitoring panels — someone noticed abnormal behavior from GatewayZEVM, a contract that was supposed to handle cross-chain messages and asset transfers under predetermined rules, and began to be suspected of "doing things it shouldn't do." As more detected anomalies were compiled, an almost irrefutable conclusion gradually took shape: the central entry point of the ZetaChain cross-chain smart contract platform — the cross-chain gateway contract GatewayZEVM — was likely being exploited.

On the same day, the security team Slow Mist released its first technical dissection. The report did not shy away from the most critical aspect: the attack directly targeted the `call` function in the GatewayZEVM contract, the central interface responsible for initiating cross-chain calls, which was pointed out to have almost no proper access control or input validation. In other words, any user could initiate cross-chain calls through it, exposing the entire system to attacks. Slow Mist unraveled the attack chain: the attacker constructed forged cross-chain events, tricking the relayer into believing these events were valid cross-chain requests, allowing it to execute arbitrary operations on the target chain, including malicious calls and fund transfers.

After Slow Mist's analysis was released, from the afternoon to evening of April 28, multiple Chinese crypto media outlets such as Deep Tide TechFlow, PANews, and Odaily Planet Daily quickly followed up, translating technical terms like "GatewayZEVM::call lacks access control and input validation" and "forged cross-chain events driving relayers" into more widely disseminated keywords, pushing them onto the timelines of the entire Chinese crypto community. By the end of that day, "the cross-chain gateway of ZetaChain was breached" was no longer just a suspicion in technical corners, but a fact written into news headlines.

Meanwhile, as technical details were revealed bit by bit, the industry began to draw comparisons between this incident and previous cross-chain bridge attacks caused by issues of permission verification and input validation. More and more people realized that this was not an isolated accident, but a recurrence of old issues in the security design of cross-chain protocols: the permission boundaries of gateway contracts were drawn too wide, leaving relayers virtually unprotected against forged events.

On the timeline of April 28, what was most directly torn apart was not only the security boundary of GatewayZEVM but also the narrative that ZetaChain had been trying to maintain — a reliable smart contract platform capable of carrying cross-chain messages and asset transfers has now been confirmed to have fatal flaws in its core gateway contract. In the absence of verified data on specific losses, what users first lost was their intuitive sense of security about this cross-chain system; and for ZetaChain, the challenge was a more difficult one to address: when the cross-chain gateway is exposed as being open to arbitrary user-initiated high-risk cross-chain calls, who would still dare to believe that this entry point remains secure?

Forged Cross-chain Events: GatewayZEVM Called Arbitrarily

To let a cross-chain system betray its users, the most straightforward way is to let it issue a "seemingly completely compliant" cross-chain request. The attacker targeted GatewayZEVM using this approach.

By design, the `call` function of GatewayZEVM is the total entry point for cross-chain calls, responsible for converting a request from a certain chain into a cross-chain event recognizable by the relayer, after which the relayer completes the execution on the target chain. The problem is that Slow Mist's preliminary analysis has pointed out that this entry has neither proper access control nor sufficient input validation — any user can directly call it without the system questioning "who are you?" or "are you qualified to initiate this cross-chain call?"

Under such conditions, what the attacker needed to do was greatly simplified: they didn't need to control the official relayer or break a private key, they just needed to submit a "disguised as normal business" cross-chain request to GatewayZEVM from their own address. Since the `call` function itself lacks access control, this request would be accepted without question by the gateway; due to the lack of input validation, key fields in the request — who to call on the target chain, what operation to execute, and whether it involved fund transfers — would also not be scrutinized seriously.

From the outside, this appears to be a cross-chain event issued from the official GatewayZEVM contract. The logic of the relayer is thus misled: it sees "a legitimate cross-chain instruction issued from the gateway contract," not "a malicious payload constructed by some unknown address." Thus, this forged cross-chain event was taken seriously by the relayer, which executed it on the target chain according to usual protocols.

Once this step is reached, the relayer becomes the attacker's remote manipulator. Slow Mist pointed out that attackers use this forged event to drive the relayer to execute arbitrary operations on the outside or the target chain—including initiating malicious calls and triggering high-risk behaviors like fund transfers. On the surface, these operations are "commands issued proactively by the cross-chain gateway"; in reality, they are just false commands inserted into the system by attackers via an unguarded `call` function.

This risk path is extremely straightforward:
GatewayZEVM::call open to all users → no access control → no strict input validation → forged cross-chain events treated as real instructions → relayer executes arbitrary calls and fund transfers on the target chain.
On April 28, 2026, this cross-chain channel, which should have been tightly sealed, was proven to be equally open to attackers.

Slow Mist Speaks: Attack Attribution Ferments in the Security Circle

In the preceding moment, this breached risk path was merely a cold, hard combination of on-chain trails and function calls; by April 28, Slow Mist translated it into a language understandable to the security community. Their preliminary technical analysis pointed directly to the root cause of ZetaChain's attack being the lack of access control and input validation in the call function of the GatewayZEVM contract, a design flaw that allowed any user to initiate cross-chain calls through GatewayZEVM.

In Slow Mist's narrative, GatewayZEVM::call was no longer a neutral tool but transformed into "a universal key to any chain": anyone could hold it, and anyone could use it to construct cross-chain calls. The absence of permission checks and strict input validation meant that forged cross-chain events could be treated as real instructions by the system, leading to the relayer being driven to execute malicious calls and fund transfers, and this chain link was clearly identified.

This attribution analysis was quickly amplified by the media. Multiple Chinese crypto media outlets, including Deep Tide TechFlow, PANews, and Odaily Planet Daily, launched reports one after another on April 28, quoting Slow Mist's characterization of GatewayZEVM::call and incorporating technical conclusions like "lack of access control and input validation" and "allowing any user to initiate cross-chain calls" into narratives aimed at a larger readership. The originally limited dissemination radius of the technical report was expanded throughout the Chinese crypto community by these media rewrites and shares.

It is worth noting that these reports concentrated on a unified technical perspective pointing to Slow Mist, rather than an official review. Research briefs also clearly indicated that there were currently no verified specific loss amounts or affected addresses; as of the publicly available information that day, ZetaChain had yet to issue a detailed official report to confirm or correct these judgments. Thus, in this time window of information asymmetry, the preliminary conclusions of the security team naturally occupied the narrative high ground.

This scene is not unfamiliar: in many instances of cross-chain protocol incidents, security teams often first provide technical breakdowns, identifying responsibilities on gaps in permission verification and input validation, while project parties are either still investigating or considering their wording. Slow Mist's "trial" of GatewayZEVM is like another public experiment — security teams present technical evidence, the media amplifies and enhances emotional narratives, and the community internalizes these conclusions in retweets and comments, treating them as a "temporary official version" of the event.

In this narrative experimental field, the relationship between security teams and project parties often oscillates between cooperation and confrontation. One side views the lack of access control and input validation in the call function as irrefutable technical attribution, while the official explanations remain unoffered; whoever's version is believed first shapes the perception of this cross-chain attack in the collective memory. The story of ZetaChain on this day was also written down in this game.

Recurring Nightmare of Cross-chain: Industry Alarm Rings Again

The day of ZetaChain is destined not to be regarded as an isolated incident. With Slow Mist's preliminary analysis and various Chinese media amplifying on April 28, research briefs quickly delivered a more brutal positioning: this is not a strange and unique black swan, but a "standard plot" that keeps appearing in the world of cross-chain protocols — multiple cross-chain bridges have previously fallen due to similar permission and input validation issues, and now it was simply GatewayZEVM's turn.

If we disassemble each cross-chain incident into components, ZetaChain's situation can almost be precisely aligned with that familiar risk curve: a gateway contract responsible for handling cross-chain messages and asset transfers, endowed with high authority, but leaving gaps in basic permission checks and input validation. Slow Mist pointed out that the GatewayZEVM::call function allows any user to initiate cross-chain calls through this contract without sufficient access control, meaning that the boundaries which should be patrolled by the system are left to "anyone" to test. The research brief also clearly stated that such vulnerabilities are typical in cross-chain protocols, and ZetaChain merely materialized this abstract risk curve into today's security incident.

In cross-chain architecture, whether bridges or gateways, a common point is that they often require a relayer to transport events from the source chain to be executed on the target chain. In theory, relayers are merely messengers, responsible for delivering messages; however, in the narrative of real attacks, they repeatedly become critical vulnerabilities. Because once the upstream gateway contract fails to guard the “entry point,” allowing forged cross-chain events to be constructed, the relayer will passively accept this "forged document," executing operations on the target chain that should not have occurred.

The problem with ZetaChain lies at the starting point of this chain link. The lack of access control and input validation in the GatewayZEVM::call function allowed attackers to construct forged cross-chain events, deceiving the system to compel the relayer to perform arbitrary operations — including malicious calls and high-risk actions such as fund transfers. At this time, the relayer is no longer a simple messenger, but a manipulated executor: it does not determine "whether this is a legitimate user request"; it merely completes its tasks faithfully according to the contract and event logs. Once the entry is breached, the backend becomes a platform for automated and precise attacks.

This is why the industry sees the ZetaChain incident as another eruption of "industry common ailments." Cross-chain bridges and gateways bear the responsibility of executing "cross-chain authority" centrally, yet they often stumble in two fundamental dimensions of design: who has the authority to initiate a call? Is the incoming data validated? When these two questions are processed simply or even overlooked, the entire cross-chain path reverts to a primitive state — anyone capable of constructing events has the opportunity to direct the relayer to exercise "will" on another chain.

As discussions about the April 28 incident continued, the topic itself shifted from "ZetaChain had problems" to "how should cross-chain gateways be designed for access control and input validation." In the absence of an official review report and specific loss data, a consensus conclusion offered by research briefs is being amplified: as long as cross-chain protocols continue to rely on relayers to execute information and operations from the source chain on the target chain, access checks and input validation at the entry point are not optional; they are the only defenses against the classic attack chain of "forged events — relayer execution — cross-chain assets or states being rewritten." The alarm sounded by ZetaChain this time is not an isolated warning, but a collective reminder for the entire cross-chain industry: the future of cross-chain first needs to traverse its own security past.

From This Incident: Next Steps in Cross-chain Security

From the moment GatewayZEVM was breached, what was truly exposed was not simply a mistake in a single function, but a repeated pitfall that cross-chain contracts encountered during their design phase: treating the "gateway" as an ordinary business contract, handing over high-risk capabilities to an unrestrained entry.

In the ZetaChain incident, the root cause identified by Slow Mist — the lack of access control and input validation in the GatewayZEVM::call function — is merely a symptom, underlying which are a series of misinterpretations that should have been avoided at the design level:

● Designing high-permission functions as universal interfaces easily callable by anyone, defaulting to assume that any user can drive cross-chain execution without first asking "who is qualified to issue this command?"
● Treating input validation as "a check that can be supplemented later," allowing unconstrained parameters to pass through the gateway to be executed by the relayer.
● Continuing to employ a single-chain mindset in cross-chain scenarios, defaulting to "as long as the relayer is good, the events are trustworthy," ignoring that the source message itself also requires authentication and constraints.

These misconceptions combine to create a typical attack surface: as long as attackers can construct forged cross-chain events, they can exploit the `call` interface's lack of permission checks and input validation to drive the relayer to perform arbitrary operations — just as this incident has demonstrated.

Improvements in cross-chain security must deduce design guidelines in reverse from here, rather than relying on post-event patches.

The first layer is access control. Cross-chain gateways are not public toolboxes but dispatch centers for high-risk operations. The design should return to some seemingly trite principles that were clearly overlooked in this incident:
● The principle of least privilege: Different types of cross-chain calls should separate roles and capabilities, avoiding "one function governing all cross-chain abilities."
● Whitelisting high-risk paths: Limiting only specific callers and specific modules to trigger critical logic in the gateway, preventing any external account from issuing cross-chain execution commands directly.
● Layered authorization: Separating "who can initiate cross-chain requests," "who can approve," and "who can actually execute," reducing the possibility of single point failures.

The second layer is input validation. The lack of input validation in the GatewayZEVM::call function has been repeatedly emphasized in public analyses, reminding cross-chain contract designers that parameters are not merely "transport workers," but part of the security boundary:
● Strict parameter checks: Performing format and range checks on key fields like chain ID, target address, function selector, amount, and data length, rejecting abnormal or ambiguous inputs.
● Binding messages to sources: Ensuring by design that cross-chain messages must carry verifiable source information rather than allowing the relayer to "guess" which chain the event is from.
● Authenticating cross-chain message sources: Even through event-driven designs, requiring messages to meet specific proofs or signature constraints rather than allowing them through based solely on "appearance."

The third layer centers on monitoring and defending against the behavior of relayers. The core path of this attack involved the attacker using forged events to deceive the system, causing the relayer to execute malicious operations passively. This indicates that simply relying on "assuming the relayer to be honest" is insufficient:
● Embedding observability into the design for relayer behavior: Ensuring that every cross-chain execution leaves traceable on-chain marks for subsequent audits and real-time monitoring.
● Establishing alerts for abnormal behaviors: Enabling timely identification and triggering of manual or automatic interventions when the relayer makes frequent cross-chain calls to abnormal target addresses or using abnormal parameters within a short period.
● Reserving "emergency brakes" at the protocol layer: Being able to freeze specific channels or functionalities when detecting relayers driven by forged events, rather than allowing attacks to propagate in "autopilot."

It must be emphasized that as of now, research briefs explicitly state: there is no verified data on key information such as specific loss amounts, affected wallet addresses, attacker addresses, and official response actions regarding this incident. This means that while the technical issues have become relatively clear, various statements surrounding "how much loss was incurred," "who was affected," and "how the project party is handling it" are likely still at the rumor and estimation level.

The early stages of security events are always the times when rumors are densest. Particularly in high-sensitivity scenarios such as cross-chain attacks, unverified screenshots, transfer records, and anonymous leaks can easily be treated as "facts," spreading rapidly in the community. However, in the absence of official reviews and extensive evidence, it is difficult to distinguish whether this information represents fragments of the truth or amplifiers of panic.

For readers, what is truly valuable is the confirmed technical analysis and officially released information, rather than speculative numbers or story-like rumors. The ZetaChain incident provides a clear lesson template: ignoring access control and input validation in the design phase ultimately pushes the relayer into traps set by attackers; while the information vacuum following the incident may allow panic to replace facts.

Next steps in cross-chain security must not only focus on fixing a single `call` function but systematically exclude the exposed design blind spots from the next generation of cross-chain gateways; simultaneously, it also involves learning restraint after each incident, maintaining necessary skepticism and patience towards unverified "details." Only by tightening both technical and narrative aspects can we truly chance that the next similar incident remains a threat model confined to paper.

Join our community to discuss and become stronger together!
Official Telegram group: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh
OKX benefits group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance benefits group: https://aicoin.com/link/chat?cid=ynr7d1P6Z

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。