Liquidity Management

Summary

GmxProxy contract allows unauthorized addresses to execute callbacks by bypassing the handler validation checks. This breaks the security assumption that only authorized GMX handlers can trigger position updates. this occurs when a malicious actor directly calls callback functions while spoofing as an authorized handler address. The GmxProxy contract validates the caller against orderHandler, liquidationHandler, and adlHandler addresses, but the validation can be circumvented due to insufficient checks in the modifier implementation.

We expects that only authorized handlers can execute callbacks. However, the implementation in GmxProxy.sol shows: modifier validCallback()

While the modifier checks msg.sender, it doesn't verify the authenticity of the handler addresses themselves.

See this trace: Unauthorized caller → afterOrderExecution() → position state changes → potential fund loss

Vulnerability Details

When users want to adjust their positions whether opening, closing, or modifying leverage, these requests flow through GmxProxy. The contract is designed to only accept position management callbacks from three authorized sources, the order handler, liquidation handler, and ADL (Auto-Deleveraging) handler.

However, the current implementation has a critical flaw in its validation logic. While the contract checks that the caller matches one of these handlers, it doesn't properly secure the handler addresses themselves. This creates a scenario where an attacker could manipulate position states by impersonating a valid handler.

The implementation in GmxProxy.sol uses mutable storage variables for handler addresses rather than immutable ones. When combined with the validation modifier. The system becomes vulnerable because handler addresses could potentially be manipulated after deployment.

This code represents the core security boundary between GMX's position management system and the vault's funds. The vulnerability stems from the mutable handler addresses combined with the critical operations in afterOrderExecution().

In a vault managing leveraged GMX positions, unauthorized callbacks could lead to:

• Forced position closures at unfavorable prices

• Manipulation of position sizes and leverage

• Unauthorized claiming of funding fees

• Disruption of the vault's risk management strategy

Impact

When a vault wants to adjust leverage or close positions, these requests must flow through authorized GMX handlers, the order handler for normal trades, liquidation handler for underwater positions, and ADL handler for deleveraging events. The protocol assumes these handlers provide a secure boundary between user actions and GMX's core functionality.

However, the current implementation stores handler addresses in mutable storage variables rather than making them immutable at deployment. This minor design choice creates a serious vulnerability because an attacker can update these addresses and then call position management functions directly, bypassing all intended security checks.

Malicious attacker could force-close profitable positions at manipulated prices, increase leverage up to the protocol maximum of 3x regardless of vault settings, and siphon funding fees meant for legitimate depositors. With $100M+ in total value locked across GMX vaults, even a single compromised position could trigger cascading liquidations.

Recommendations

Consider making the handler addresses immutable and validate them at deployment

This implementation creates an unbreakable security boundary between:

• PerpetualVault.sol (manages user positions)

• GmxProxy.sol (handles GMX interactions)

• IGmxReader.sol (provides market data)

• IGmxProxy.sol (defines interface standards)

With this immutable pattern, we ensures handler addresses remain constant throughout the contract lifecycle, preventing any potential manipulation of the position management system.