预言机被夺舍，代币价格被随意篡改，750 万美元被洗劫一空

KiloEx 被盗的原因仅仅是因为一次权限校验的失守。

它只是忘了关一扇门，攻击者就被放了进来，把整个价格系统接管了。

让我们先来看看攻击是怎么发生的。

KiloEx 的永续合约架构中，价格由内部预言机合约 KiloPriceFeed 更新，理论上只有平台的 Keeper 模块能调用 setPrices()。

但链上的权限路径是一条串联链条：

MinimalForwarder → PositionKeeper → Keeper → KiloPriceFeed

攻击者就是在最上游的 MinimalForwarder 找到了突破口。

简单地说，黑客只是「换上了员工服」，就从大门一路畅通无阻地走到了「价格控制室」，没有安保人员检查他的身份。

KiloEx 架构中的 MinimalForwarder 合约允许用户伪造签名，指定任意地址发起调用，但调用过程中并没有验证调用路径的真实性。

具体做法是，攻击者通过构造签名，逐层欺骗调用链，从 MinimalForwarder 一路走到 KiloPriceFeed，最终控制了 setPrices() 函数，获得了修改预言机价格的权限。

从技术上说，它不是一个点的问题，而是一整套权限架构上的「默认信任」失效。

一旦拿到价格控制权，攻击方式就变得非常简单直接。

攻击者用篡改后的价格低位开仓，高位平仓，反复在 Base、opBNB、BNB Chain 等链上操作，将平台的资金池洗劫一空。

那么，KiloEx 的问题到底出在哪里呢？

根据 @SlowMist_Team 的分析，KiloEx 遭受攻击的根本原因在于其合约架构中的访问控制缺失，尤其是在 MinimalForwarder 合约中。攻击者利用该合约的漏洞，伪造签名并绕过权限验证，最终控制了预言机价格的更新。

具体问题如下：

• 调用链入口缺乏身份校验：
  MinimalForwarder 合约的 execute() 函数未对调用者的身份进行严格验证，允许攻击者伪造签名并指定任意地址发起调用。
• 目标函数权限控制不足：
  预言机合约 KiloPriceFeed 中的 setPrices() 函数缺乏足够的访问控制，未能有效限制调用来源。
• 调用路径未设限：
  攻击者能够通过构造特定的调用路径，逐层调用 PositionKeeper、Keeper 等合约，最终达到修改价格的目的，表明调用路径的深度与方向未被有效限制。
• 签名验证机制薄弱：
  MinimalForwarder 合约在执行过程中未能有效验证签名的真实性和上下文，导致攻击者能够利用伪造的签名通过验证。
• 缺乏最终调用者的边界条件设定：
  合约未设定「最终调用者必须为平台合约」的边界条件，使得非授权的外部地址也能成功调用关键函数。

这不是一个 bug，而是一种信任假设上的设计失败。

一条调用链越长、涉及的模块越多，就越需要在每一层都加上最基本的限制：

我是谁？
我从哪来？
我能做什么？

KiloEx 没有做这些检查，最终把最关键的价格控制权交到了黑客手中。

当前进展与官方回应

目前，KiloEx 官方已确认漏洞原因，并表示漏洞已定位，预计将很快修复，也已经暂停前端服务，并联合多个安全机构追踪攻击者资金流向。

但对于用户来说，真正重要的不是「修复」，而是明白一个事实：

合约安全，从来不是靠祈祷别人不去攻击，
而是从设计上就不允许任何人攻击。

权限控制，是最容易忽略的安全底线

权限控制本是智能合约中最基础、最明确的一项设计，
却也往往是最容易被忽视的。

当一个协议需要跨合约、跨模块协作时，
任何一处未验证的入口、任何一个默认放行的路径，
都可能成为整个系统被接管的起点。

KiloEx 被攻击的事件不只是对项目方的考验，
更是对所有智能合约开发者的一次公开考题：

• 你愿意为了开发效率，跳过那一层层显得「多余」的校验逻辑吗？
• 你真的知道，合约的每一次授权调用，背后是谁在发起、从哪跳转、又指向哪里吗？

你疏忽的每一行代码，都会有人认真研究。
你知道得越少，别人就越容易利用得更多。

这一次的学费，是 750 万美元。