The afterOrderExecution function in GmxProxy
processes GMX order executions without verifying if the order is still valid according to the perpetual vault’s latest state. This creates a scenario where outdated orders, submitted earlier but executed later by GMX, can modify the vault’s position even after it has changed due to manual adjustments or liquidations. The issue arises because afterOrderExecution
directly interacts with the vault without checking if the position or strategy has changed since order submission:
Since there is no vault-side validation, this function can apply an order to a position that has already been closed or changed, leading to unexpected re-opening of positions, unintended leverage modifications, or risk exposure mismatches.
The primary impact is that an outdated or unintended GMX order can execute and alter the perpetual vault’s position, potentially reopening closed positions, increasing leverage beyond intended limits, or interfering with liquidations, leading to financial loss and strategy inconsistency.
Before executing an order in afterOrderExecution
, the contract should validate whether the perpetual vault’s position still matches the expected state of the order, ensuring that the order is still relevant and not stale.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.