2026 年 4 月 28 日这天，ZetaChain 的跨链网关被撕开了一道真正致命的口子。这个原本负责在多链之间转运资产、转发消息的 GatewayZEVM 合约，被曝出遭遇安全攻击，跨链调用不再是由受信任的流程驱动，而是可以被攻击者任意“编导”。从这一天开始，ZetaChain 不再只是一个跨链智能合约平台的技术叙事，它被迫面对一种更现实的身份——被利用的攻击入口。

慢雾在同一天给出了初步的技术归因，把矛头直接指向 GatewayZEVM 合约中的一个核心接口：`call` 函数。这个本该受严格约束的跨链调用入口，缺乏必要的访问控制和输入验证，允许任意用户通过网关发起跨链调用。攻击者正是抓住了这一点，通过构造伪造的跨链事件，诱导中继器在目标链上执行本不该发生的操作，打开了恶意调用与资金转移的攻击面，而这一设计缺陷，也被视为跨链协议常见安全问题的又一次重演。

然而，在技术细节被迅速拆解的同时，最直观、最容易被追问的那部分信息——到底损失了多少、哪些地址受到了影响——却迟迟没有出现明确答案。研究简报与媒体报道反复强调：目前尚无经过验证的具体损失金额、攻击者地址或受影响钱包地址数据，这些关键信息被标记为缺失或待验证。于是，在 4 月 28 日这一天，唯一可以确定的，是 GatewayZEVM 的安全边界被突破；至于这道裂缝究竟撕开了多大的伤口，只能先留在问号里。

跨链网关失守：攻击在4月28日爆发

4 月 28 日这天，关于 ZetaChain 的传闻最先在技术圈的聊天群和安全监控面板上浮现——有人注意到 GatewayZEVM 的行为异常，这个本应只在既定规则下处理跨链消息与资产转移的合约，开始被怀疑“做了它不该做的事”。随着更多监测到的异常被汇总，一个几乎无法被粉饰的结论逐渐成形：ZetaChain 这一跨链智能合约平台的中枢入口——跨链网关合约 GatewayZEVM，很可能正处在被利用的过程中。

同一天，安全团队慢雾给出了第一份技术解剖。报告没有回避最关键的部分：攻击的落点正是 GatewayZEVM 合约中的 call 函数，这个负责发起跨链调用的中枢接口，被指出几乎没有像样的访问控制和输入验证。换句话说，任意用户都可以通过它发起跨链调用，这本身就把整个系统的攻击面暴露在外。慢雾将攻击链路抽丝剥茧：攻击者通过构造伪造的跨链事件，诱骗中继器误以为这些事件是真实合法的跨链请求，从而在目标链上执行任意操作，包括恶意调用与资金转移等高危动作。

在慢雾的分析抛出之后，4 月 28 日当天下午到晚上，深潮 TechFlow、PANews、Odaily 星球日报等多家中文加密媒体迅速跟进，将“GatewayZEVM::call 缺乏访问控制与输入验证”“伪造跨链事件驱动中继器”这些技术措辞，翻译成更易被广泛传播的关键词，推送到整个华语加密社区的时间线上。到这一天结束前，“ZetaChain 的跨链网关被攻破”已经不再是技术角落里的怀疑，而是被写入新闻标题的既成事实。

与此同时，随着技术细节被一点点公开，业内开始把这次事件与此前多起因权限校验和输入验证问题引发的跨链桥攻击相互对照。越来越多的人意识到，这并不是一场孤立的事故，而是跨链协议在安全设计上的老病复发：网关合约的权限边界被画得太宽，中继器在伪造事件面前几乎不设防。

4 月 28 日这条时间轴上，最直接被撕开的，不只是 GatewayZEVM 的安全边界，也是 ZetaChain 一直试图维持的叙事——一个可以可靠承载跨链消息与资产转移的智能合约平台，如今被证实其最核心的网关合约存在致命缺陷。在具体损失数据尚未被验证的空白中，用户首先失去的，是对这套跨链体系本身的直觉安全感；而 ZetaChain，要面对的，则是一个更难修复的问题：当跨链网关被曝出可以被任意用户借道发起高危跨链调用时，谁还敢轻易相信这道入口依旧牢靠。

伪造跨链事件：GatewayZEVM 被任意调用

要让一套跨链系统背叛自己的用户，最直接的方式，就是让它自己发出一条“看起来完全合规”的跨链请求。攻击者对 GatewayZEVM 下手的，就是这一条路。

按设计，GatewayZEVM 的 `call` 函数是跨链调用的总入口，负责把一条来自某条链的请求，转成中继器可以识别的跨链事件，再由中继器在目标链上完成后续执行。问题在于，慢雾的初步分析已经点明：这个入口既没有像样的访问控制，也没有足够的输入验证——任意用户都可以直接调用它，而系统不会追问“你是谁”、“你有没有资格发起这条跨链调用”。

在这样的前提下，攻击者要做的事情就被极度简化了：不需要控制官方中继，也不需要攻破私钥，他只要用自己的地址，向 GatewayZEVM 提交一份“伪装成正常业务”的跨链请求即可。由于 `call` 函数本身缺乏访问控制，这份请求会被网关照单全收；由于缺乏输入验证，请求中的关键字段——目标链上要调用谁、要执行什么操作、是否伴随资金转移——也不会被认真审查。

从外部看，这就是一条从官方 GatewayZEVM 合约发出的跨链事件。中继器的逻辑也就此被牵着走：它看到的是“网关合约发出的合法跨链指令”，而不是“某个陌生地址构造的恶意 payload”。于是，这条伪造的跨链事件被中继器当真，按照既定流程，在目标链上执行。

一旦走到这一步，中继器就成了攻击者的远程机械臂。慢雾指出，攻击者正是通过这种伪造事件，驱动中继器在外部或目标链上执行任意操作——包括发起恶意调用，以及触发资金转移等高危行为。表面上，这些操作是“跨链网关主动下达的指令”；实际上，它们只是攻击者通过一个毫无遮拦的 `call` 函数，塞进系统内部的假命令。

这条风险路径极其直接：
GatewayZEVM::call 对所有用户敞开 → 没有访问控制 → 没有严格的输入验证 → 伪造的跨链事件被当作真实指令 → 中继器在目标链上执行任意调用与资金转移。
在 2026 年 4 月 28 日这一天，这条原本应该严密封锁的跨链通道，被证明对攻击者同样敞开。

慢雾发声：攻击归因在安全圈发酵

前一刻，这条被攻破的风险路径还只是链上轨迹和函数调用的冷冰冰组合；到 4 月 28 日当天，慢雾把它翻译成了安全圈听得懂的语言。其发布的初步技术分析直接点名：ZetaChain 被攻击的根本原因，在于 GatewayZEVM 合约的 call 函数缺乏访问控制和输入验证，这一设计缺陷让任意用户都可以通过 GatewayZEVM 发起跨链调用。

在慢雾的叙述中，GatewayZEVM::call 不再是一个中立的工具，而变成了“通往任何链的万能钥匙”：谁都可以握在手里，谁都可以用它构造跨链调用。缺少权限校验、缺少严格的输入验证，意味着伪造的跨链事件可以被系统当成真实指令，中继器在目标链上被驱动去执行恶意调用与资金转移，这条链路被清晰地指认出来。

这份归因分析很快被媒体放大。深潮 TechFlow、PANews、Odaily 星球日报等多家中文加密媒体在 4 月 28 日相继推出报道，引用慢雾对 GatewayZEVM::call 的定性，把“缺乏访问控制和输入验证”“允许任意用户发起跨链调用”这样的技术结论，搬进面向更大读者群体的叙事里。技术报告原本有限的传播半径，被这些媒体转写、转发后扩展到了整个华语加密社区。

值得注意的是，在这些报道集中出现的，是统一指向慢雾的技术视角，而不是官方复盘。研究简报中也明确标注，目前尚无经过验证的具体损失金额或受影响地址等数据；截至当日公开资料，ZetaChain 方面还没有一份细致的官方报告来确认或修正这些判断。于是，在信息不对称的时间窗口里，安全团队的初步结论自然占据了叙事高地。

这类场景并不陌生：多起跨链协议事件中，往往都是安全团队先给出技术拆解，把责任锁定在权限校验和输入验证的缺口上，而项目方要么还在排查，要么在权衡措辞。慢雾这一次对 GatewayZEVM 的“审判”，就像是再一次的公开实验——安全团队拿出技术证据，媒体负责放大和情绪渲染，社区则在转发和评论中内化这些结论，把它们当作对事件的“临时官方版本”。

在这样的叙事实验场中，安全团队与项目方之间的关系，往往在合作与对抗之间摇摆。一边是把 call 函数缺乏访问控制与输入验证视为铁证的技术归因，一边是尚未出场的官方解释；谁的版本更早被相信，谁就更早塑造了这起跨链攻击在集体记忆中的样子。ZetaChain 这一日的故事，也在这样的博弈中被写下第一稿。

一再重演的跨链噩梦：行业警钟再响

ZetaChain 这一日注定不会被当成孤立事故。随着慢雾的初步分析和多家中文媒体在 4 月 28 日同步放大，研究简报很快给出了一个更残酷的定位：这不是一场离奇而独特的黑天鹅，而是一种在跨链协议世界里反复出现的“标准剧情”——此前已经有多个跨链桥在类似的权限和输入验证问题上跌倒，这一次只不过轮到了 GatewayZEVM。

如果把每一次跨链事故都拆解成组件，ZetaChain 的位置几乎可以精准对齐到那条熟悉的风险曲线：一个负责处理跨链消息与资产转移的网关合约，被赋予高度权能，却在最基础的权限校验和输入验证上留下缺口。慢雾指出，GatewayZEVM::call 函数允许任意用户通过该合约发起跨链调用，而没有足够的访问控制，这种设计让原本该由系统把关的边界，被交给了“任何人”来试探。研究简报也明确写道，这类漏洞在跨链协议中具有典型性，ZetaChain 只是把这条抽象的风险曲线具象成了今天的安全事件。

在跨链架构里，桥也好，网关也罢，一个共同点是：它们往往需要一个中继器，把源链上的事件，搬运到目标链上执行。按理说，中继器只是信使，负责把消息送达；但在现实的攻击叙事中，它却一次次变成关键薄弱点。因为一旦上游的网关合约没有把好“入口关”，允许伪造的跨链事件被构造出来，中继器就会被动接过这份“伪造公文”，在目标链上严丝合缝地执行本不该发生的操作。

ZetaChain 的问题正出在这条链路的起点。GatewayZEVM::call 函数缺乏访问控制与输入验证，让攻击者得以构造伪造的跨链事件，欺骗系统，让中继器在外部或目标链上执行任意操作——包括恶意调用与资金转移等高危行为。此时的中继器，不再是单纯的传话者，而是被操控的执行者：它并不判断“这是不是一个真实的用户请求”，它只忠实地按照合约和事件日志完成任务。入口一旦失守，后端就会成为自动化精确攻击的舞台。

这也是为什么业内会把 ZetaChain 事件视作“行业通病”的再一次爆发。跨链桥和跨链网关承担的是“跨链权力”的集中执行职责，但设计上却常常在两个最朴素的维度上栽跟头：谁有权发起调用？传入的数据是否被验证？当这两个问题被简单处理甚至被忽略时，整条跨链路径就退回到一种原始状态——任何能构造事件的人，都有机会指挥中继器在另一条链上“代行意志”。

随着 4 月 28 日这起事件被持续讨论，话题本身也从“ZetaChain 出了问题”转向“跨链网关到底该如何设计访问控制和输入验证”。在尚无官方复盘报告和具体损失数据的背景下，研究简报给出的一个共识性结论正在被放大：只要跨链协议继续依赖中继器在目标链上执行来自源链的信息与操作，那么入口处的权限校验与输入验证，就不是可选项，而是唯一能阻止“伪造事件—中继器执行—跨链资产或状态被改写”这条经典攻击链一再重演的防线。ZetaChain 这次敲响的，并不是一记孤立的警钟，而是对整个跨链行业的集体提醒：跨链的未来，先要穿过自己的安全过去。

从这次事故出发：跨链安全的下一步

从 GatewayZEVM 被攻破的那一刻起，真正暴露出来的，其实不是某一个函数写错，而是跨链合约在设计阶段一再踩的老坑：把“网关”当成普通业务合约，把高危能力交给了一个缺乏约束的入口。

在 ZetaChain 这次事件里，慢雾点名的根本原因——GatewayZEVM::call 函数缺乏访问控制与输入验证——只是症状，背后对应的是一整套在设计层面就应该避免的误区：

● 把高权限函数设计成“谁都能调用”的通用接口，默认任何用户都可以驱动跨链执行，而不是先问一句“谁有资格下达这道命令”。
● 把输入验证当成“可以以后再补的校验”，允许未约束的参数穿过网关，最终交给中继器去执行。
● 在跨链场景下仍沿用单链思维，默认“只要中继器是好的，事件就是可信的”，忽略了源头消息本身也需要认证与约束。

这些误区叠加在一起，就造就了一个典型的攻击面：攻击者只要能构造伪造的跨链事件，就能利用缺乏权限校验和输入验证的 call 接口，驱动中继器在目标链上执行任意操作——正如这次事件所呈现的那样。

跨链安全的改进，必须从这里反向推导设计准则，而不是指望事后补丁。

第一层是访问控制。跨链网关不是公共工具箱，而是高危操作的调度中心。设计时需要回到一些看似老生常谈、但在此次事件中被明显忽视的原则：
● 最小权限原则：不同类型的跨链调用拆分角色与能力，避免“一个函数统管全部跨链能力”。
● 高危路径白名单化：限定只有特定调用方、特定模块可以触发网关中的关键逻辑，杜绝任意外部账户直接下达跨链执行指令。
● 分层授权：把“谁能发起跨链请求”“谁能批准”“谁能实际执行”拆开，降低单点失守的可能。

第二层是输入验证。GatewayZEVM::call 函数缺乏输入验证这一点，已经在公开分析中被反复强调，这也再一次提醒跨链合约设计者，参数不是“搬运工”，而是安全边界的一部分：
● 严格参数校验：对链 ID、目标地址、函数选择器、金额与数据长度等关键字段进行格式和范围检查，拒绝异常或模糊输入。
● 把消息与来源绑定：设计上确保跨链消息必须携带可验证的来源信息，而不是让中继器去“猜”这是从哪条链来的事件。
● 对跨链消息来源进行认证：哪怕是通过事件驱动，也应要求消息满足特定的证明机制或签名约束，而不是单靠“看上去像”就放行。

第三层，则是围绕中继器行为的监控与防御。此次攻击的核心路径，是攻击者通过伪造事件欺骗系统，让中继器被动执行恶意操作。这说明，仅靠“假定中继器诚实”是不够的：
● 在设计中为中继器行为埋下可观测性：让每一次跨链执行都留下可追踪的链上痕迹，便于事后审计与实时监控。
● 建立异常行为告警：当中继器在短时间内频繁对异常目标地址、异常参数发起跨链调用时，能够及时识别并触发人工或自动干预。
● 在协议层预留“紧急刹车”：当检测到中继器被伪造事件驱动时，能够冻结特定通道或功能，而不是让攻击在“自动驾驶”里一路扩散。

需要强调的是，截至目前，研究简报明确指出：关于本次事件的具体损失金额、受影响钱包地址、攻击者地址以及官方处置动作等关键信息，尚无经过验证的数据。这意味着，在技术问题已经相对清晰的同时，围绕“损失到底有多大”“谁被打到了”“项目方内部怎么处理”的各种说法，很大概率仍停留在传言和估计层面。

安全事件的早期阶段，一向是谣言最密集的时刻。尤其在跨链攻击这种舆论敏感度极高的场景里，未经证实的截图、转账记录、匿名爆料，很容易被当作“事实”在社区中快速扩散。但在缺乏官方复盘与充分证据的前提下，这些信息很难区分是真相的碎片，还是恐慌的放大器。

对读者而言，真正有价值的，是已经被确认的技术分析和正式发布的信息，而不是猜测性的数字、故事化的传闻。ZetaChain 这次事故提供的是一个清晰的教训模板：设计阶段忽略访问控制与输入验证，最终会把中继器推入攻击者设计好的陷阱；而事件发生后的信息真空，则可能让恐慌取代事实。

跨链安全的下一步，不只是修好一个 call 函数，而是把这次暴露出来的设计盲区，系统性地从新一代跨链网关中剔除；同时，也是在每一次事故后学会克制，对尚未被证实的“细节”，保持必要的怀疑与耐心。只有在技术和叙事两个层面同时收紧，我们才有机会让下一次类似的事故，真的只停留在纸面上的威胁模型里。

加入我们的社区，一起来讨论，一起变得更强吧！
官方电报（Telegram）社群：https://t.me/aicoincn
AiCoin中文推特：https://x.com/AiCoinzh
OKX 福利群：https://aicoin.com/link/chat?cid=l61eM4owQ
币安福利群：https://aicoin.com/link/chat?cid=ynr7d1P6Z

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