060.md

Cheesy Clay Dinosaur

Medium

Front-Running Vulnerability in executeOrder() of Manager.sol

Summary

In Manager.sol, inside executeOrder(), the order state (isSpent = true;) is updated after execution, allowing:

Front-running: Attackers can monitor the mempool, execute the same order with higher gas fees, and get their transaction mined first.

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/periphery/contracts/TriggerOrders/Manager.sol#L157-L163

Root Cause

No response

Internal Pre-conditions

1. A valid pending order exists for a market.
2. An attacker monitors the mempool for executeOrder() calls.
3. The contract does not enforce immediate invalidation (isSpent is set after execution).

External Pre-conditions

1. Ethereum mempool must be publicly accessible, allowing attackers to see pending executeOrder() transactions.
2. MEV bots or attackers must have faster gas-adjusting strategies to submit transactions with higher gas.

Attack Path

1. User submits a valid order execution: executeOrder(ETHMarket, Alice, 123);
2. Attacker detects the transaction in the mempool.
3. Attacker submits an identical transaction but with higher gas fees. executeOrder(ETHMarket, Alice, 123); // Attacker front-runs this order
4. The attacker's transaction is mined first, executing Alice’s order under their control.
5. Alice's original transaction gets mined later, failing due to order.isSpent = true;.

Impact

Users suffer losses due to manipulated execution prices. MEV bots or malicious actors gain unfair advantages over legitimate users. Some examples of impact,

1. A stop-loss order is front-run, and the attacker buys at a lower price before it executes.
2. The user’s stop-loss gets triggered at a worse price, and the attacker sells at a profit.

PoC

No response

Mitigation

No response