Liquidity Management

Summary

The createOrder function in the GmxProxy contract approves token spending for gmxRouter without explicitly resetting prior approvals. This could lead to a scenario where an old allowance remains valid, which might be exploited if gmxRouter is compromised. While the contract does not grant infinite approvals (i.e., type(uint256).max), best practices dictate resetting prior approvals before assigning a new one to prevent unintended token drains.

Vulnerability Details

Impact: Risk of unintended token spending if gmxRouter is compromised

Location:

Function: createOrder

Relevant Code:

Root Cause:

The function directly approves orderData.amountIn for gmxRouter without first setting the previous approval to zero. If an earlier approval is still active, it remains valid until explicitly overridden. This behavior could allow unintended token access if gmxRouter is compromised or behaves maliciously.

Impact

• If gmxRouter is safe: No immediate impact, but best practices suggest mitigating this.

• If gmxRouter is compromised or upgraded maliciously: Any leftover approval from a prior transaction could be exploited, leading to unintended token transfers.

• If an attacker gains control over gmxRouter: They could call transferFrom() using the unrevoked old allowance, draining funds.

Tools Used

• Manual Code Review

• Slither (Static Analysis)

• OpenZeppelin SafeERC20 Best Practices Review

Mitigation

To prevent any potential exploitation, modify the approval logic to first reset the previous allowance before assigning a new one:

This ensures that no prior approvals persist and that only the exact required amount is approved, eliminating potential risks.

Conclusion

The issue is not a critical vulnerability but a medium-severity risk that can be mitigated with a simple fix. Implementing the recommended mitigation will ensure safer token approvals, reducing the likelihood of unintended token transfers if gmxRouter is ever compromised.