Written by: BlockSec
GMX suffered a hacker attack, resulting in losses exceeding $40 million. The attacker exploited a reentrancy vulnerability and opened a short position while the contract had leverage enabled to carry out the attack.
The root of the problem lies in the incorrect usage of the executeDecreaseOrder function. The first parameter of this function was supposed to be an external account (EOA), but the attacker passed in a smart contract address. This allowed the attacker to re-enter the system during the redemption process, manipulate the internal state, and ultimately redeem assets far exceeding the actual value of the GLP they held.
Normal GLP Redemption Mechanism
In GMX, GLP is a liquidity provider token that represents a share of the treasury assets (such as USDC, ETH, WBTC). When a user calls unstakeAndRedeemGlp, the system calculates the amount of assets to be returned using the following formula:
redeemamount = (userGLP / totalGLPsupply) * AUM
Where AUM (Assets Under Management) is calculated as:
AUM = Total value of all token pools + Global unrealized losses from shorts - Global unrealized profits from shorts - Reserved amounts - Preset deductions (aumDeduction)
This mechanism ensures that GLP holders receive a proportional share of the actual assets in the treasury.
Issues After Leverage is Enabled
When enableLeverage is turned on, users can open leveraged positions (long or short). Before redeeming GLP, the attacker opened a large short position in WBTC.
As soon as the short position was opened, it increased the global short size, and since the price had not yet changed, the system assumed that this short was at a loss. This unrealized loss was counted as "assets" in the treasury, artificially inflating the AUM. Although the treasury did not actually gain additional value, the redemption calculation was based on this inflated AUM, allowing the attacker to obtain assets far exceeding what they were entitled to.
Attack Process
In Conclusion
This attack exposed serious flaws in GMX's leverage mechanism and reentrancy protection design. The core issue lies in the redemption logic's excessive trust in AUM, failing to conduct sufficient security checks on its components (such as unrealized losses). Additionally, the key function's assumption about the caller's identity (EOA vs contract) lacked mandatory verification. This incident serves as a reminder to developers that when dealing with sensitive financial operations, it is crucial to ensure that the system state cannot be manipulated, especially when introducing complex financial logic (such as leverage and derivatives), to prevent systemic risks from reentrancy and state contamination.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
