How GMX V1 Lost $42 Million to a Reentrancy Attack?

Rahul RaviRahul Ravi
3 min read

On July 9th, 2025, GMX V1, once a leading decentralized perpetual exchange on Arbitrum, fell victim to a sophisticated reentrancy exploit, resulting in a loss of over $42 million. Although the funds were later returned by the attacker (who kept a $5 million white-hat bounty), this incident sheds light on critical smart contract vulnerabilities that projects must proactively guard against.

What Happened?

GMX V1 had funds still locked in its old smart contracts even after its v2 upgrade in 2023. These contracts became the target of an attacker who discovered a reentrancy flaw in the executeDecreaseOrder function, a core component in GMX's position management logic.

Typically, when a user wants to reduce a position, the executeDecreaseOrder function is triggered via GMX’s keeper bots through the orderbook contract. However, the attacker exploited a weakness that allowed a malicious contract, instead of an externally owned account (EOA), to serve as the caller during this execution.

This malicious contract (0x7D3BD…) took control of the flow during the gas refund phase. In doing so, it gained the ability to interact with the system mid-transaction, creating an opportunity for reentrancy, where a contract repeatedly re-enters the same function before the previous execution is complete.

Exploiting the Price Logic

Once the attacker had control, they bypassed key routing checks by directly calling the increasePosition() function in the Vault contract. This shortcut allowed them to manipulate the average short price calculation, an essential component for determining the value of GLP (GMX Liquidity Provider Token).

The result? The attacker drove down the average BTC short price from $109,515.05 to $1,913.705, creating massive distortion in the platform’s internal accounting. With this manipulated data, the attacker used a flash loan to buy GLP tokens at a cheap rate (around $1.45) and later redeemed them at over $27 each, taking advantage of the spike caused by the altered Assets Under Management (AUM).

This clever manipulation of internal price logic is a textbook example of how a smart contract, if not hardened properly, can be tricked into calculating asset values inaccurately, leading to devastating financial consequences.

Could This Have Been Prevented?

Yes, and quite easily. The primary issue was the lack of validation on the account parameter in executeDecreaseOrder. Had the protocol enforced a check to ensure the caller was an EOA—or at the very least used EIP-7702-like methods to prevent contracts from masquerading as users—this attack vector could have been blocked entirely.

Other mitigation steps could include:

  • Reentrancy guards

  • Checks for contract code presence (extcodesize)

  • Validating the call sequence through the router layers

  • Using better gas refund logic that doesn’t allow mid-flow hijacking

Want to dive deeper?

We’ve unpacked the full technical breakdown, attack transactions, contract interactions, and prevention strategies in our complete blog.
👉
Read the full analysis of GMX hack

Final Thoughts

Although the attacker returned the funds, the GMX V1 hack serves as a clear reminder that security is never optional. Even mature protocols can carry legacy vulnerabilities that become ticking time bombs. As more complex interactions are layered into DeFi platforms, the need for deep, multi-layered audits becomes non-negotiable.

0
Subscribe to my newsletter

Read articles from Rahul Ravi directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Rahul Ravi
Rahul Ravi