The ParaSwapUtils.swap()
function executes swaps using ParaSwap but does not implement anti-front-running protections. Attackers monitoring the mempool can detect high-value swaps and insert their transactions ahead, profiting from price differences at the victim’s expense.
Lack of Slippage Control:
The function directly calls ParaSwap using the provided callData
without ensuring minimum output amounts.
Attackers can manipulate liquidity pools before execution, making users receive fewer tokens than expected.
Mempool Attack Risk:
Since the transaction includes an off-chain computed swap route, MEV bots can copy the swap parameters and execute the trade first (sandwich attack).
Approval Risks:
The function blindly approves the token transfer proxy for the swap amount each time. If an attacker replaces the ParaSwap contract address with a malicious contract, it could drain user funds.
PoC
Users executing swaps on ParaSwap are vulnerable to front-running and sandwich attacks.
Victims receive fewer tokens than expected, while attackers profit by exploiting the manipulated price.
High-value swaps (e.g., large ETH trades) are especially attractive to MEV bots.
Manual Review, Foundry
Implement slippage protection by ensuring a minimum output amount.
Use private mempool transactions (e.g., Flashbots) to avoid public exposure.
Time-delay execution mechanisms could help mitigate MEV attacks.
Use permit approvals instead of repeated safeApprove()
calls to minimize token approval risk.
Slippage and deadline are handled externally. Paraswap implementation used by the current code (behind the proxy): https://etherscan.io/address/0xdffd706ee98953d3d25a3b8440e34e3a2c9beb2c GMX code: https://github.com/gmx-io/gmx-synthetics/blob/caf3dd8b51ad9ad27b0a399f668e3016fd2c14df/contracts/order/OrderUtils.sol#L150C15-L150C33
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.