Liquidity Management

Summary

GmxProxy contract allows unauthorized handlers to reset the order queue state, potentially disrupting ongoing order execution flows. This breaks the core security assumption that only valid GMX handlers can modify critical order state. Centers around the queue state management in GmxProxy. When an order is created through createOrder(), the queue stores a requestKey. Its require that only authorized handlers (orderHandler, liquidationHandler, or adlHandler) should be able to reset this queue state. However, the contract allows other actors to modify this state, breaking the handler validation invariant. Looking at the modifier validCallback

The validation exists in the modifier but isn't consistently applied across all state-modifying functions. The queue state can be modified through: createOrder() → afterOrderExecution() → queue reset

The critical path shows how the queue state transitions without proper handler validation.

A malicious attacker could:

1. Disrupt ongoing order execution flows

2. Cause order tracking mismatches between GMX and the proxy

3. Lead to stuck orders or failed callbacks

This directly impacts the vault's ability to reliably execute trades and manage positions.

Vulnerability Details

The GmxProxy contract manages a queue of trading orders, where each order has a unique requestKey and must follow specific execution protocols through GMX. The GmxProxy contract maintains an OrderQueue struct that tracks ongoing order execution: createOrder

the vulnerability is from the interaction between these components, while the validCallback modifier protects callback operations, the queue state can be modified directly in other functions without similar protections. The createOrder function shows where the queue gets updated, but lacks state transition validation.

When a vault initiates a trade through createOrder(), the contract stores the order's requestKey in this queue. This requestKey is crucial, it's like a flight's transponder code, allowing GMX to track and execute the order correctly.

The contract expects only three authorized handlers to clear this queue:

• orderHandler (regular trades)

• liquidationHandler (liquidations)

• adlHandler (auto-deleveraging)

However, the current implementation allows the queue to be reset without proper validation. This would be like allowing anyone, not just air traffic controllers, to clear flight tracking data.

When an unauthorized reset occurs:

1. The vault loses track of its pending order on GMX

2. Callbacks from GMX may fail or be misrouted

3. Trading flows (deposit/withdraw/position changes) can become permanently stuck

For example, if a user deposits 1000 USDC to open a 2x ETH long position, an unauthorized queue reset could leave their funds locked in limbo - the order exists on GMX but the vault can't track it anymore.

Impact

The GmxProxy contract acts as a bridge between user vaults and GMX's trading infrastructure. It maintains an order queue that synchronizes position management between these systems. When a vault initiates a trade, the queue tracks the order's unique requestKey until GMX's asynchronous execution completes.

The vulnerability emerges in how this queue state gets modified. While the contract carefully validates handlers through its validCallback modifier, direct state modifications to the queue structure bypass these checks entirely. This creates a dangerous mismatch between GMX's order tracking and the vault's position management.

Let's examine a concrete scenario. A vault deposits 100,000 USDC to open a 2x ETH long position. The GmxProxy creates the order and stores its requestKey. During GMX's execution window, an attacker resets the queue. When GMX attempts to callback with the execution result, the position update fails because the queue has lost track of the original order. The 100,000 USDC position becomes effectively frozen, the funds exist on GMX but the vault can't manage them.

The core state variables tell the story: #L38-L40

When queue.requestKey gets cleared without proper validation, it breaks the fundamental assumption that only orderHandler, liquidationHandler, or adlHandler can modify order tracking state. This violates the protocol's key invariant around position management integrity.

Recommendations

We need to address both queue initialization and reset scenarios

This implementation maintains the protocol's existing security boundaries while adding proper state transition controls. The perpVault can initialize orders, and only authorized handlers can modify queue state during execution callbacks.