Summary

A critical vulnerability exists in the swap state tracking mechanism due to improper handling of the swapProgressData structure. This flaw allows residual data from failed or mixed swap operations (DEX/GMX) to persist, leading to incorrect calculations of swapped amounts and global shares. Attackers can exploit this to manipulate share distributions, resulting in financial losses for users and protocol instability.

Vulnerability Details

Affected Code

Root Cause

1. Shared State Without Isolation:

   • The swapProgressData struct is shared across all swap operations (DEX and GMX).

   • Residual data from prior swaps (especially failed ones) is not cleared, causing cross-operation contamination.

2. No Reset on Failure:

   • After a GMX swap fails (e.g., due to slippage or cancellation), swapProgressData.remaining retains its previous value.

   • Subsequent swaps incorrectly inherit stale data, leading to over/under-swapping.

3. Mixed Swap Types:

   • DEX and GMX swaps update the same swapProgressData, but their execution paths (success/failure) are not mutually isolated.

Attack Scenario

1. Step 1: User A initiates a DEX swap (5 ETH → Collateral Token) → succeeds.

   • swapProgressData.swapped is updated correctly.

2. Step 2: User B initiates a GMX swap (5 ETH → Collateral Token) → fails (e.g., price impact too high).

   • swapProgressData.remaining = 5 persists.

3. Step 3: User C initiates a new swap.

   • Contract erroneously treats the residual swapProgressData.remaining = 5 as valid.

   • Total swapped amount becomes swapped += new_output + 5 (incorrectly inflated).

Impact

• Financial Losses: Users may lose funds due to incorrect share distribution or swap amounts.

• Protocol Insolvency Risk: Repeated exploitation could drain collateral reserves.

• Loss of Trust: Incorrect accounting undermines user confidence in the protocol.

• Governance Manipulation: Attackers could accumulate excess shares to influence governance votes.

Tools Used

manual review