cheatcode - Front-Running Occurs in executeOrder function

[sherlock-admin2]

cheatcode

medium

Front-Running Occurs in executeOrder function

Summary

In the executeOrder function, the executor of the order is determined by msg.sender, which is the address that calls the function.

Vulnerability Detail

The executeOrder function does not appear to have mechanisms in place to prevent front-running. Since it relies on msg.sender to determine who is executing the order, anyone who can see the transaction before it is mined has the opportunity to front-run it.

Impact

Poc:

1. A user submits a transaction to execute an order with specific terms.
2. A miner or observer sees this pending transaction in the mempool (the collection of all pending transactions).
3. The malicious actor creates their own transaction with a higher gas price to execute the same order.
4. Because miners prioritize transactions with higher gas prices, the attacker's transaction is confirmed first.
5. The attacker benefits from the conditions intended for the original transaction, potentially at a more favorable price.

Code Snippet

https://github.com/sherlock-audit/2023-12-flatmoney/blob/main/flatcoin-v1/src/DelayedOrder.sol#L378

Tool used

Manual Review

Recommendation

Use Commit-Reveal Schemes or submarine sends

[sherlock-admin]

1 comment(s) were left on this issue during the judging contest.

takarez commented:

invalid

[nevillehuang]

Invalid, front-running is not an an issue on Base given they operate with a private sequencer as seen in comments of #49. Additionally, execution of orders are permisionless via keepers (anybody can be a keeper), so they are expected to compete to earn keeper fees.