Written by: BlockSec
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.
The root cause 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 unrealized losses on shorts - Global unrealized profits on shorts - 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 immediately increases the global short scale, the system defaults to an unrealized 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, there was a lack of mandatory verification of the caller's identity (EOA vs contract) for key functions. This event once again reminds developers that when dealing with financially sensitive operations, they must ensure that system states cannot be manipulated, especially when introducing complex financial logic (such as leverage and derivatives), and must prevent systemic risks from reentrancy and state pollution.
