On July 9, 2025, a critical design flaw in GMX V1’s architecture enabled an attacker to drain over $40 million from the protocol’s Arbitrum deployment. The exploit wasn’t due to an obscure zero-day or gas optimization mishap; it was a failure to constrain user-controlled receiver logic in decreasePosition, exposing the protocol to a cross-contract reentrancy attack.

By injecting a malicious contract as the receiver, the attacker reentered Vault.increasePosition mid-transaction, bypassing mandatory routing through PositionRouter and PositionManager. This allowed them to manipulate the average short price of BTC, miscalculate pending PnL, and inflate the value of GMX’s GLP token. With the GLP price artificially elevated, the attacker redeemed at a premium, draining liquidity from the protocol.

The incident triggered a 28% drop in GMX token price, forced emergency shutdowns on both Arbitrum and Avalanche, and raised existential questions about the upgradeability and safety guarantees of modular DeFi architectures.

This exploit was preventable. Olympix’s proactive security tools would have flagged the dynamic receiver path as exploitable, generated test mutants that simulate mid-transaction reentrancy, and enforced end-to-end invariants around price integrity. This wasn’t a bug in the code; it was a blind spot in the security model. Olympix was built to catch exactly that.

Timeline of Events

• July 9, 2025 – 12:30 PM UTC.  A reentrancy-based exploit is executed on the GMX V1 protocol on Arbitrum, draining approximately $40M from the GLP liquidity pool. The attacker manipulates the average BTC short price to mint and redeem GLP tokens at distorted values.
• Immediately after exploit. Hexagate detects the anomaly; trading on Avalanche is paused as a precaution. The attacker begins dispersing stolen funds across multiple wallets, converting assets primarily to ETH.
• July 9, 2025 – PM UTC. GMX issues an on-chain message offering a 10% white-hat bounty in exchange for 90% fund return. Legal action is threatened if the deadline (48 hours) is missed.
• July 10, 2025. The attacker responds on-chain, agrees to return funds, and begins partial repayments.
  
  • ~$9M in ETH is sent to GMX’s designated recovery address.
  • ~$10.5M in FRAX is returned in two tranches.
• July 11, 2025. GMX confirms that ~$20M (≈50% of stolen funds) has been recovered. The protocol disables GLP minting and redemption on Arbitrum and begins processing remaining V1 position closures.
• July 12–13, 2025. Community and governance discussions begin regarding reimbursement frameworks, long-term V1 deprecation, and V2 migration acceleration.

Technical Root Cause

Core Design Vulnerability: Arbitrary Receiver Execution

The entry point of the exploit was the createDecreaseOrder function in OrderBook.sol, which allowed users to specify any receiver address to receive withdrawn funds. Critically, this receiver could be a contract with executable logic—opening the door to callback-based reentrancy.

Although OrderBook used a nonReentrant modifier, it only protected against reentry within that contract. Once execution transferred to the receiver contract, the attacker invoked Vault.increasePosition() from within the callback context—crossing contract boundaries and bypassing expected routing through PositionRouter and PositionManager.

Exploitation of Price Calculation Invariants

Under normal circumstances, GMX relies on routing through PositionRouter to enforce the correct calculation of average short prices—used to compute pending PnL and, by extension, GLP value. By invoking increasePosition() directly, the attacker skipped these safeguards.

This allowed them to:

• Drive the short average price of BTC from $109,505 to $1,913.
• Open large leveraged positions using flash loans.
• Exploit the distorted PnL to artificially inflate GLP token value above $27.
• Redeem the inflated GLP tokens for underlying assets at an outsized gain.

Execution Flow Breakdown

1. Submit a decrease position with a malicious contract as the receiver.
2. Funds are transferred before vault state is finalized.
3. receiver contract triggers a reentrant call to Vault.increasePosition.
4. Bypass occurs: no average short price calculation, state assumptions violated.
5. Exploit concludes with GLP overvaluation and liquidity drain.

This wasn't a logic bug; it was a failure to enforce security-critical sequencing across modular contract boundaries. A design that trusted routing layers to enforce invariants was fatally flawed when those layers could be bypassed.

4. Systemic Design Flaws

Implicit Trust in Routing Contracts

GMX V1’s architecture relied on PositionRouter and PositionManager to enforce invariant logic around price updates and position sizing. But the Vault contract itself did not enforce these rules internally; it assumed that only trusted paths would invoke sensitive functions like increasePosition.

That assumption broke down the moment a user could trigger those functions indirectly through a malicious receiver. Once call ordering can be manipulated from the outside, all downstream state assumptions are invalid.

Incomplete Reentrancy Defense

The use of nonReentrant in OrderBook was superficial. It didn’t apply across the call chain or across contracts. Once control is passed to an external address (especially one the user controls), reentrancy isn’t just possible; it’s expected.

Without a cross-contract reentrancy guard or a circuit-breaker around price-sensitive operations, GMX V1 was structurally vulnerable to callback-driven logic injections.

Premature Fund Transfers

Funds were transferred to the receiver before all price calculations and state transitions had completed. This violated a core best practice in contract safety:

Transfers must occur only after all critical state updates and invariant checks.

By transferring early, the protocol handed execution control to the attacker while it was still mid-transition—exposing the Vault to race conditions and unguarded state.

Lack of Invariant Enforcement at the Vault Level

The Vault contract—the system's most critical state holder—was passive. It neither validated incoming positions nor enforced post-conditions. It assumed correctness was guaranteed by upstream logic.

But in modular architectures, defense-in-depth isn’t optional. Without local assertions on state integrity, any breach upstream cascades directly into economic failure.

This wasn't an implementation oversight. It was a systemic failure to build protocols with composable safety guarantees—where each module enforces what it must, regardless of who called it or how.

Olympix Report: Receiver Path Risk Confirmed

During internal source inspection, Olympix flagged the GMX V1 decreasePosition flow as vulnerable due to a user-controlled receiver parameter in the execution path.

Confirmed by Source Review

• receiver is user-controlled in DecreasePositionRequest.
• Vault executes fund transfers to the receiver on position close.
• Transfers trigger fallback or receive() logic if the receiver is a contract.
• Vault uses ReentrancyGuard, which blocks reentrancy at direct entrypoints—but not across contract boundaries.

Identified Risk Scenarios

• If the receiver contract calls into orchestrator or state-dependent logic (e.g. Vault.increasePosition) before all invariants are finalized, the system is vulnerable.
• Any fund transfer before invariant enforcement creates a race window for exploitation.
• Potential for griefing or callback-based execution abuse exists, especially with non-standard tokens or upgradeable orchestrators.

Olympix's Recommendation

• Lock all orchestrator pathways against cross-contract reentrancy, not just Vault.
• Defer fund transfers to the end of execution flow; never mid-state update.
• Assert core invariants before giving control to external contracts.
  
  

Olympix labeled this vector as “not an immediate critical threat”—but only if all orchestrator paths are guarded. GMX V1’s failure was assuming Vault's ReentrancyGuard was sufficient. It wasn’t.

This was the exact scenario Olympix was built to prevent: early identification, deep source inspection, PoC-ready findings. 

Recommendations for Protocol Developers

Never Assume a Safe Receiver

If users can specify a receiver address, treat that field as executable code. Any contract address can include fallback logic, reentrancy traps, gas griefing payloads, or unexpected token hooks. Default to distrust.

• Require receiver whitelisting for sensitive fund flows.
• Detect contract receivers on-chain and enforce conditional logic or guardrails.
• For token transfers, prefer pull-based models over push when possible.

Enforce State Invariants Before External Transfers

No ETH or token should be transferred before:

• All relevant state transitions are finalized.
• All protocol-specific invariants (e.g., price correctness, exposure bounds) are validated.

This applies especially to orchestrator patterns where state spans multiple contracts.

Guard All Entry Points, Not Just the Vault

ReentrancyGuard in Vault isn’t enough if attackers can reenter through other public/external orchestrators. All modules involved in fund flows or pricing logic must be:

• Guarded with reentrancy protections,
• Sequence-aware in their state updates,
• Designed to fail closed on unexpected callbacks.

Integrate Proactive Testing Pipelines

Don’t wait for auditors. Build security into the development pipeline:

• Use static analysis tools that understand protocol-wide context and data flow, not just line-level issues.
• Employ mutation testing to simulate attacker-controlled contract interactions.
• Define and test explicit invariants around economic behavior, not just code correctness.

Olympix enables all of the above. Had GMX V1 used it, the exploit path would’ve been dead on arrival.

Don’t Fragment Core Logic

Every additional contract split adds surface area. GMX V1 split execution across PositionRouter, PositionManager, and Vault—then trusted that users wouldn’t jump over the routing layer.

In critical flows like price updates or margin enforcement, all logic must live in the same contract or be cryptographically enforced (e.g. via Merkle proofs or signature validation). Architectural trust assumptions must be airtight.

Closing Thoughts

The GMX V1 exploit was not a black swan. It was a blueprint for failure: one that’s been seen before and will be seen again wherever protocol logic trusts routing layers and assumes benign receivers.

This wasn’t a missed require. It was a fundamental lapse in architectural threat modeling. The attacker didn’t break the Vault; they sidestepped it, exploiting a trusted-but-user-controlled parameter to distort price logic and drain liquidity.

Olympix flagged this path during source inspection. We didn’t need the exploit to prove the risk; it was visible in the code. With static detection, mutation testing, and invariant checks, this exploit was entirely preventable.

DeFi is composable. So are its risks. If protocols don’t build composable defenses —tools, testing, and architecture that assume the worst —attackers will always find the cracks.

The fix isn’t more audits. It’s security that runs with your code from the first commit.

Empower your organization to find and resolve smart contract vulnerabilities in-house, prior to the first audit. Protect your assets with Olympix's enterprise-grade security tools. Get a free demo!

Sources

GMX V1 Exploit on Arbitrum: Root Cause and Next Steps

$40M GMX Reentrancy Exploit Leads Week of Smart Contract Failures