Losses Exceeding $40 Million: Analysis of GMX Attack Principles

Author: BlockSec

GMX suffered a hack, 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 use 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 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 short unrealized losses - Global short unrealized profits - Reserved amount - Preset deduction (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.

Since the short position increased the global short size as soon as it was opened, and the price had not yet changed, the system defaults to considering this short as a loss, which is 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

Attack Transaction

https://app.blocksec.com/explorer/tx/arbitrum/0x03182d3f0956a91c4e4c8f225bbc7975f9434fab042228c7acdc5ec9a32626ef?line=93

Conclusion

This attack exposed serious flaws in GMX's leverage mechanism and reentrancy protection design. The core issue lies in the excessive trust placed on the asset redemption logic regarding AUM, without sufficient security checks on its components (such as unrealized losses). Additionally, the assumption about the caller's identity (EOA vs contract) in key functions lacks 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.