#4 GMX Incident: Cross-Contract Reentrancy Bypasses a Four-Year-Old Guard

On July 9, 2025, the decentralized perpetual platform GMX experienced an exploit [1, 2] targeting their V1 contract on the Arbitrum network, resulting in a loss of approximately $42 million. The attacker exploited a cross-contract reentrancy vulnerability to manipulate the GLP price, then used the distorted price to siphon underlying assets from GMX V1's liquidity pools.

Background

GMX V1 [3] is a decentralized perpetuals trading platform deployed on Arbitrum. It allows users to trade perpetual contracts on multiple crypto assets with leverage in a permissionless and non-custodial manner. GMX V1 follows a single multi-asset pool design, where liquidity for all supported assets is aggregated into a unified Vault system.

Position Management in GMX

The position management in GMX is a two-step process. Specifically, users create increase/decrease orders via interacting with the contracts OrderBook or PositionRouter. Then, the authorized keeper account executes users' orders, which updates the global short data in the contract ShortTracker and the corresponding state of the contract Vault. The following two figures demonstrate the two execution paths (the orderbook-execution and router-execution paths) for managing positions in GMX. In this incident, the attacker used both paths to manipulate the global short data and realize profits.

The Orderbook-execution Path

The Router-execution Path

GMX Vault

The contract Vault in GMX is responsible for managing users' positions and assets (e.g., finalizing the profit and loss). To avoid malicious interactions, the contract Vault is only accessible when the "leverage window" is opened (i.e., the variable isLeverageEnabled in the contract Vault is set to true via the function Timelock.enableLeverage()). This validation enforces that order execution must follow the fixed paths (orderbook-execution and router-execution).

GMX Short Tracker

The contract ShortTracker is responsible for tracking and updating the global short data (e.g., the variable globalShortAveragePrice) during the order execution. According to the orderbook-execution and router-execution paths, the function updateGlobalShortData() of the contract ShortTracker is invoked before executing users' orders to sync the latest global short data. This step ensures correct profit and loss realization for users' positions.

Decreasing WETH Position

Different from other orders, decreasing the WETH position via the orderbook-execution path will invoke the function _transferOutETH() in the contract OrderBook to withdraw WETH tokens and transfer the native ETH tokens to users. If the recipient _receiver is a contract, sendValue() could trigger the contract's fallback() function, introducing a potential reentrancy vulnerability. In this incident, the attacker repeatedly exploited this reentrancy vulnerability to extract significant profits.

GLP Token

The GLP (GMX Liquidity Provider) token represents the unified shares for various assets in the contract Vault. Users are allowed to provide and redeem assets by minting and burning GLPs.

The GLP price could be calculated in the following equations:

$$\text{GLPPrice}=\frac{\text{AUM}}{\text{GLPTotalSupply}}\backslash text\{GLPPrice\}=\; \backslash frac\{\backslash text\{AUM\}\}\{\backslash text\{GLPTotalSupply\}\}$$

$$\text{AUM}=\sum _{i=asset[0]}^{assets}({\mathrm{\Delta }}_{\text{GlobalShort[i]}}+{\text{AUM}}_{\text{Other[i]}})\backslash text\{AUM\}\; =\; \backslash sum^\{assets\}\_\{i\; =\; asset[0]\}(\backslash Delta\_\{\backslash text\{GlobalShort[i]\}\}\; +\; \backslash text\{AUM\}\_\{\backslash text\{Other[i]\}\})$$

$${\mathrm{\Delta }}_{\text{GlobalShort[i]}}=\frac{\text{globalShortSize}\times (\text{AssetMarketPrice}-\text{globalShortAveragePrice})}{\text{globalShortAveragePrice}}\backslash Delta\_\{\backslash text\{GlobalShort[i]\}\}\; =\; \backslash frac\{\; \backslash text\{globalShortSize\}\; \backslash times\; (\backslash text\{AssetMarketPrice\}\; -\; \backslash text\{globalShortAveragePrice\}\; )\; \}\{\; \backslash text\{globalShortAveragePrice\}\; \}$$

Where:

• GLPTotalSupply represents the total supply of the GLP tokens.
• AUM consists of the following two components.
  • ${\mathrm{\Delta }}_{\text{GlobalShort}}\backslash Delta\_\{\backslash text\{GlobalShort\}\}$ represents the uPnL (i.e., unrealized Profit and Loss) of all short positions.
  • ${\text{AUM}}_{\text{Other}}\backslash text\{AUM\}\_\{\backslash text\{Other\}\}$ represents the provided liquidity of the LP plus the unrealized uPnL of all long positions. This term remained nearly unchanged throughout the incident prior to profit realization.
• AssetMarketPrice is the market price (in USD) of the underlying asset.
• globalShortSize is the sum (in USD) of all short positions.
• globalShortAveragePrice is the average entry price of the aggregated global short position.

In this incident, the attacker skewed globalShortAveragePrice to manipulate the GLP price and extract profits.

Vulnerability Analysis

The root cause is a cross-contract reentrancy vulnerability in the contract OrderBook. As described in Background, decreasing WETH positions via the orderbook-execution path triggers a low-level fallback call to the receiver through _transferOutETH(). The function carries a nonReentrant modifier, but this guard only prevents reentrancy within the OrderBook contract itself, not cross-contract calls to the Vault.

Under normal operation, the Vault's increasePosition() can only be called through PositionRouter and PositionManager, which invoke ShortTracker to update globalShortAveragePrice before each position change. The attacker created orders with a malicious contract as the receiver, and during the fallback call, directly called increasePosition() on the Vault, bypassing PositionRouter/PositionManager and the associated ShortTracker update. By repeatedly opening and closing short positions without updating globalShortAveragePrice, the attacker progressively skewed the variable. The distorted value inflated the GLP price, allowing the attacker to extract profits by minting and redeeming GLPs.

Attack Analysis

The attacker launched a series of transactions manipulating the global short data and realizing the profit. Specifically, this incident could be divided into three phases: Preparation, Price Manipulation, and Profit Realization. All related transactions are listed in the following table.

Preparation Phase

1. (Tx 1) The attacker deployed the attack contract, which is used as the asset receiver during the order execution. The attack contract contained a malicious fallback() function.

2. (Tx 2) The attacker created an increase WETH-long order for the attack contract in the contract OrderBook.

   

3. (Tx 3) A Keeper executed the attacker's increase order (created in step 2), which opened a WETH-long position for the attack contract. (Tx 3).

   

4. (Tx 4) The attacker created a decrease WETH-long order for the attack contract in the contract OrderBook.

   

Manipulation Phase

5. (Tx 5) A Keeper executed the attack contract's decrease WETH-long order (created in step 4) via the orderbook-execution path. The execution path invoked _transferOutETH(), triggering the malicious fallback() function in the attack contract.

   Since fallback() was invoked during the "leverage window", the attack contract directly interacted with the contract Vault to open a WBTC-short position (via increasePosition()) without updating globalShortAveragePrice, and subsequently created a decrease/close WBTC-short order.

   

6. (Tx 6) A Keeper executed the decrease WBTC-short order (created in step 5) via the router-execution path. The execution also created a decrease WETH-long order via the fallback mechanism in the contract PositionRouter.

   Since the WBTC-short position was opened without updating globalShortAveragePrice, closing the position while updating the variable caused an unexpected drop in globalShortAveragePrice.

   

7. (Tx 7-14) The attacker repeated steps 5-6 four times. As a result, globalShortAveragePrice was skewed from 1.08e35 to 1.9e33.

   

Profit Realization Phase

8. (Tx 15) A Keeper executed the decrease WETH-long order (created in Tx 14) via the orderbook-execution path. This execution triggered the profit realization logic in the attack contract due to the reentrancy vulnerability in the contract OrderBook.

   

   1. In the fallback invocation, the attack contract first borrowed a flash loan of 7,538,567e18 USDC.

   2. The attack contract invoked mintAndStakeGlp() to mint 4,129,578e18 GLPs using 6,000,000e18 USDC.

   3. The attack contract invoked Vault.increasePosition() to open a WBTC-short position with the remaining 1,538,567e18 USDC. Because WBTC's global short data was extremely skewed, the order execution significantly amplified AUM, sharply increasing the GLP price.

   4. The attack contract invoked unstakeAndRedeemGlp() to redeem GLPs at the amplified price for multiple assets in the contract Vault.

   5. The attack contract invoked Vault.decreasePosition() to close the WBTC-short position.

   6. The attack contract repeated steps 8.b-8.e four times to drain all assets in the contract Vault.

   7. The attack contract repaid the flash loan with a profit of nearly $42 million.

Refunding

Through negotiations with the attacker (Tx 16-18), the attacker ultimately accepted a 10% bounty and returned the remaining stolen assets (Tx 19-21).

Summary

This incident involved a multi-phase exploit against GMX V1 on Arbitrum, resulting in an estimated loss of $42 million. The attacker abused a reentrancy vulnerability on the contract OrderBook to skew the variable globalShortAveragePrice, inflating the GLP price. By leveraging the manipulated price, the attacker siphoned a significant amount of assets.

Key lessons:

• Cross-contract reentrancy: A nonReentrant modifier on a single contract does not prevent reentrancy into other contracts within the same system. Access control mechanisms that rely on a temporary flag (e.g., the "leverage window") can be bypassed when an external call occurs before the flag is reset.
• Operational Security: This attacker exploited the protocol in three distinct phases, executing a total of 15 transactions. This incident underscores the critical need for real-time monitoring, prompt alerts, and effective mitigation playbooks.

Reference

1. https://x.com/GMX_IO/status/1942955807756165574
2. https://x.com/GMX_IO/status/1943336664102756471
3. GMX V1

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

• Official website: https://blocksec.com/

• Official Twitter account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Submit a request

• 🔗 Phalcon Security APP: Book a demo

• 🔗 Phalcon Compliance