A critical state management vulnerability exists in the _runSwap function due to shared state variables across multiple swap protocols (DEX/GMX). This allows residual swap progress data from failed operations to corrupt subsequent transactions, leading to fund duplication and accounting inconsistencies. The root cause is the improper reuse of the swapProgressData structure between different swap protocols.
The swapProgressData struct tracks swap progress across operations:
When processing multi-protocol swaps:
State Contamination Sequence:
Initial Legitimate Swap
DEX swap completes partially: swapped = 5 ETH
GMX swap fails (e.g., slippage error)
Malicious Exploitation
Attacker initiates new swap with same collateral pair
Contract uses residual swapped=5 value
New swap amount calculation includes contaminated data
Attack Transaction Flow:
Double-counting of swap amounts between protocols
Artificial inflation of minted shares
Protocol insolvency due to reserve/accounting mismatch
Indirect price manipulation through fake swap volumes
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.