BlockSec：GMX 攻击原理分析

撰文：BlockSec

GMX 遭遇黑客攻击，损失超过 4000 万美元。攻击者利用了一个可重入漏洞，并在合约启用杠杆功能的情况下开空头头寸，实施了攻击。

问题的根源在于 executeDecreaseOrder 函数被错误使用。该函数的第一个参数本应是外部账户（EOA），但攻击者传入了一个智能合约地址。这使得攻击者可以在赎回过程中重新进入系统，操纵内部状态，最终赎回的资产远超过其实际持有的 GLP 价值。

GLP 正常赎回机制

在 GMX 中，GLP 是流动性提供者代币，代表对金库资产（如 USDC、ETH、WBTC）的份额。当用户调用 unstakeAndRedeemGlp 时，系统使用以下公式计算应返还的资产数量：

redeem_amount = (user_GLP / total_GLP_supply) * AUM

其中 AUM（管理资产总额）的计算方式为：

AUM = 所有 token 池的总价值 + 全局空头未实现亏损 - 全局空头未实现盈利 - 已预留金额 - 预设扣减（aumDeduction）

该机制保证了 GLP 持有者按比例获得金库的实际资产份额。

杠杆开启后的问题

当 enableLeverage 开启后，用户可以开设杠杆仓位（多头或空头）。攻击者在赎回 GLP 前，开设了大额的 WBTC 空头头寸。

由于空头一开仓便增加了全局空头规模，价格尚未变动的情况下系统默认该空头是亏损的，而这部分未实现亏损会被计为金库的「资产」，导致 AUM 人为上升。尽管金库并未实际获得额外价值，但赎回计算会基于这个虚高的 AUM，从而使攻击者获得了远超其应得的资产。

攻击流程

攻击交易

写在结尾

此次攻击暴露了 GMX 在杠杆机制与可重入保护设计上的严重缺陷。核心问题在于资产赎回逻辑对 AUM 的信任过高，未对其组成部分（如未实现亏损）进行足够审慎的安全校验。同时，关键函数对调用者身份的假设（EOA vs 合约）也缺乏强制性验证。该事件再次提醒开发者，在涉及资金敏感操作时，必须确保系统状态不可被操纵，尤其是在引入复杂金融逻辑（如杠杆、衍生品）时，更需严防重入与状态污染带来的系统性风险。