GMX Exchange Hack Explained: $42M Drained via Re-Entrancy Exploit

Written in collaboration with Blackthorn Lead Security Partner, Panprog.

‍

On July 9, 2025, GMX Exchange - one of the leading decentralized perpetual trading platforms - was exploited for over $42 million. The attacker used a complex re-entrancy technique targeting GMX V1 on the Arbitrum network to manipulate the vault accounting mechanism and the GLP token pricing.

This post breaks down exactly how the GMX exploit unfolded, including the technical code logic, transaction evidence, and a step-by-step view of the attacker’s execution flow. It also explores the broader implications for smart contract security, decentralized finance protocols, and GLP token design.

‍

Summary of the GMX Hack

‍

• Date: July 9, 2025
  
  
• Loss: ~$42 million (initially)
  
  
• Network: Arbitrum
  
  
• Protocol Affected: GMX V1 (not V2)
  
  
• Exploit Type: Re-entrancy via PositionManager.executeDecreaseOrder
  
  
• Response: GMX halted trading & GLP minting, offered 10% white-hat bounty

‍

How the Exploit Happened

‍

When Sherlock Senior Watson (Security Researcher), Panprog, was asked about how the exploit happened, he stated:

“The root of the exploit was a re-entrancy vulnerability in the GMX smart contracts, specifically within PositionManager.executeDecreaseOrder.

From OrderBook.executeDecreaseOrder, the profit (in ETH) was sent directly to the user. 

This triggered the receiver contract’s receive() function before timelock.disableLeverage() was called. That function is intended to prevent direct Vault calls by disabling leverage, but because of its delayed invocation, the attacker was able to bypass it.”

‍

Short background of this implementation:

‍

When asked about the reason this update was introduced, Panprog stated.

Initially, GMX v1 allowed users direct interaction with the Vault (which was open to oracle front-running). In 2022, it was upgraded to delayed order settlement to prevent front-running.

Since Vault is not upgradeable, PositionManager was introduced to do this and direct Vault interaction was turned off by disabling leveraged trading (disableLeverage()). PositionManager temporarily enables leveraged trading before interacting with the Vault and then disables it again.

As such, the ability to interact with the Vault directly doesn't seem dangerous: while it's not intended, it was allowed before, and it can only happen after the keeper executes an order.

Panprog was also asked how the exploitable code remained despite numerous auditors looking into the code back in 2022.

“I've seen many reentrancy possibilities in live contracts or in contests, where you can reenter, but can't do much damage. Like you can change the order of event emissions, or do something unintended, but harmless, like letting zero size order pass, which isn't allowed but doesn't cause any issues.. These are often at most low severity and so might not be reported.”

Looking back, that makes sense, so it was likely many researchers noticed a possibility of reentrancy, but due to oversight on the fact that interaction with the vault was allowed before, and they were unable to come up with any exploit scenario, they disregarded it as low severity and didn't report.

Panprog then went on to mention:

“However, there is another critical line of code in the PositionManager which must be called before each Vault interaction:”

When he described this code in more detail:

• When a user buys / sells GLP, its price is automatically calculated from the current vault assets (AUM): redeem_amount = AUM * (user GLP / GLP total supply)
• AUM is calculated from the sum of the value of all tokens in the pool, unrealized profit and loss (upnl) from the global shorts (upnl of all short positions opened by the users), amounts reserved for paying out the global longs profit and AUM deductions.
• The point of interest here is the upnl from the global shorts: it's calculated as global shorts size * (average entry price - current price) / average entry price:

• Before the upgrade, both globalShortSizes and globalShortAveragePrices were handled entirely in the Vault:

• However, after the upgrade, the formula for average prices was slightly modified and moved to the ShortsTracker contract (because Vault is non-upgradeable).
• Now AUM calculation uses Vault.globalShortSize, for size, and price is from ShortsTracker.globalShortAveragePrices:

‍

• Note, that currently ShortsTracker.isGlobalShortDataReady() returns true and shortsTrackerAveragePriceWeight = BASIS_POINTS_DIVISOR, as such GetGlobalShortAveragePrice returns shortsTracker.globalShortAveragePrices()
• While Vault global short values are calculated directly in the position change functions, ShortsTracker is a separate contract that must be manually updated. This is done in the PositionManager, but not done if Vault is interacted with directly.

“This means that if the Attacker significantly increases the short position via direct Vault interaction, the global shorts size will increase, but the global average price will not be updated, meaning that global shorts upnl will increase proportional to global shorts size increase. This will change AUM and GLP price accordingly, allowing the attacker to artificially increase or decrease GLP price by a huge amount.”

‍

The Taking of $42M funds:

‍

The attacker first bought GLP for the normal price, then inflated it with re-entrancy loops, then sold the GLP back to the Vault at an artificially inflated price. This drained nearly all the tokens held in the Vault. Total haul: $42M in ETH, BTC, USDC, and more.

‍

Attacker Flow: Step-by-Step Breakdown

Here is the exact sequence of operations performed by the attacker, as confirmed by on-chain transactions:

‍

1. Select Vulnerable Market

• The attacker chose a market (BTC) where the market price was higher than the global short average price - indicating that global shorts were currently in loss.

‍

2. Re-entrancy Loop to Inflate Global Short Size

‍

2.1 Open a small ETH long
2.2 Close the ETH long and receive a profit payout
2.3 The receiver contract’s receive() function is called, allowing re-entrancy
2.4 Within the re-entrancy, the attacker opens a large BTC short directly via the Vault

‍

• This increases Vault.globalShortSizes while keeping ShortsTracker.globalShortAveragePrices unchanged
  
  
• The system now perceives a larger loss due to inflated size and fixed average short entry price 

‍

3. Close Large BTC Short

‍

• Closing the short resets the position, but in order to keep (inflated) loss the same, the average price is reduced. The attacker repeated this several times to push the average short price lower and lower. 

‍

4. Purchase of GLP

‍

Once the global shorts' average BTC price is sufficiently reduced to create a larger impact on GLP price, the attacker bought a large amount of GLP tokens from the vault.

‍

5. Final Drain

‍

The process the Attacker went through to Drain the Funds was as follows:

5.1 Open another small ETH long
5.2 Close the long, trigger profit payout
5.3 Re-enter again via receive()
5.4 Open an extremely large BTC short directly via the Vault

• At this stage, because the average price is so low, the short appears to be at a massive loss
  
  
• This unrealized loss inflates the AUM and GLP token price dramatically

5.5 Sell all previously purchased GLP tokens

• The vault calculates GLP at a grossly inflated price and releases nearly all of its tokens

5.6 Close the large BTC short position to end the exploit loop

‍

Aftermath and Protocol Response

‍

• GMX halted all trading, minting, and redeeming for GLP on Arbitrum and Avalanche.
  
  
• GMX V2 and other protocol components were not affected.
  
  
• The attacker was offered a 10% white-hat bounty (approx. $4.2 million) if funds were returned within 48 hours.
• As this article was written, the hacker started to return funds to GMX, stating they are taking the “whitehat bounty” offered. It seems like this was an exceptionally close call that can offer some significant lessons to the Web3 community.

Market Impact

‍

• The GMX token price fell ~28% from $14 to ~$11, before rising again 13.47% in the last 24hours as the hacker accepted the whitehat bounty.
  
  
• Total value locked (TVL) on GMX V1 saw a steep decline initially, which rebounded on the return of funds.
  
  
• Competitors such as dYdX and Synthetix initially experienced a surge in user activity as capital migrated once again, until the return of funds.

‍

Lessons for Smart Contract Security

‍

• Ensure with multiple verification sources there is no reentrancy possible, even if it looks harmless on inspection of the code and there are no obvious exploit scenarios from the reentrancy, due to previous iterations of the code. 

• Ensure there are sanity checks for quick change of value, such as token or share prices: revert execution if in a short span of time the price of any asset (like GLP in this instance) changes more than a certain percentage.

• Ensure there is strict off-chain monitoring in place for any suspicious patterns, possibly automatically halting trading in extreme situations. For example, if GLP price is outside some pre-defined range at any point in time, halt operations immediately to investigate.

‍

Final Thoughts

‍

The GMX V1 exploit demonstrates how even mature protocols with battle-tested code can still fall prey to complex re-entrancy vectors and state desynchronization issues. The use of deep on-chain liquidity calculations, combined with composability, introduces subtle risks that must be guarded against.

As security partners with GMX starting with their V2, we have been assisting with this situation & are delighted to hear about the return of funds. We are looking forward to continuing to work with GMX in the future.

Sherlock is the leader in Web3 security. Protect your protocol with a full suite of cutting-edge security solutions powered by the world’s best security researchers and trusted by top Web3 companies, including Ethereum, Aave, MakerDAO, Usual, Optimism, and more.

To work with the world’s best security researchers, such as Panprog, reach out below

‍