GMX suffered a hacker attack, with losses exceeding $40 million. The attacker exploited a reentrancy vulnerability and opened a short position with leverage enabled in the contract to carry out the attack.
The root of the problem lies in the incorrect use of the executeDecreaseOrder function. The first parameter should have been 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 beyond the actual value of their held GLP.
Normal GLP Redemption Mechanism
In GMX, GLP is a liquidity provider token representing a share of vault assets (such as USDC, ETH, WBTC). When a user calls unstakeAndRedeemGlp, the system calculates the number of assets to be returned using the following formula:
redeem_amount = (user_GLP / total_GLP_supply) * AUM
Where AUM (Assets Under Management) is calculated as follows:
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 vault's actual assets.
Issues After Leverage Activation
When enableLeverage is turned on, users can open leveraged positions (long or short). Before redeeming GLP, the attacker opened a large WBTC short position.
Since opening a short position immediately increases the global short scale, the system defaults that the short is at a loss when the price has not changed, and this unrealized loss is counted as a "asset" of the vault, artificially raising the AUM. Although the vault did not actually gain additional value, the redemption calculation would be based on this inflated AUM, allowing the attacker to obtain assets far beyond what they should have received.
Attack Process
Attack Transaction
https://app.blocksec.com/explorer/tx/arbitrum/0x03182d3f0956a91c4e4c8f225bbc7975f9434fab042228c7acdc5ec9a32626ef?line=93
In Conclusion
This attack exposed serious flaws in GMX's leverage mechanism and reentrancy protection design. The core issue is the excessive trust in the asset redemption logic's AUM, without sufficient cautious security verification of its components (such as unrealized losses). Additionally, the key function lacks mandatory verification of the caller's identity (EOA vs contract). This event once again reminds developers that when dealing with financially sensitive operations, they must ensure that the system state cannot be manipulated, especially when introducing complex financial logic (such as leverage and derivatives), and must prevent systemic risks brought by reentrancy and state pollution.
