OrderBook
First Flight #43
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

Buyers are Front-Runnable via sellers Amendments

igdbaxe

Root + Impact

Fundamental design flaw in order state management that allows sellers to maliciously modify active orders during buyer transaction processing, enabling direct theft of funds and artificial price manipulation.

Description

  • Expected Behavior: Order terms (price, quantity, and expiration) should remain immutable from creation through execution to maintain market integrity and prevent manipulation.

  • Vulnerability: The amendSellOrder function permits real-time modifications to active orders while they are being processed by buyers, creating a dangerous race condition that can be exploited through transaction ordering attacks.

function amendSellOrder(...) public {
// Remaining Logic
Order storage order = orders[_orderId];
@> order.amountToSell = _newAmountToSell; // Can be changed during buy tx
@> order.priceInUSDC = _newPriceInUSDC; // Allows last-second price hikes
// Remaining Logic
}

Risk

Likelihood:

  • Guaranteed exploitation by sophisticated MEV bots that monitor pending transactions

  • All orders are vulnerable regardless of size due to public mempool visibility

  • Requires no special privileges - any seller can execute this attack

Impact:

  • Buyers receive significantly reduced asset quantities

  • Enables artificial price inflation (300x price spikes demonstrated)

  • Complete Lack of trust in order book integrity

Proof of Concept

// Full attack flow:
1. Seller creates seemingly fair order: 10 WBTC @ $30k ($300k total)
2. Buyer initiates purchase transaction (10 gwei gas)
3. Attacker front-runs with:
amendSellOrder(
orderId,
1e8, // Reduce to 1 WBTC
300_000e6, // Maintain $300k total (now $300k/BTC)
1 days
) @ 200 gwei // Higher priority gas
4. Original buy executes:
- Buyer pays $300k
- Receives only 1 WBTC (300x price increase)
5. Attacker profits:
- Steals 9 WBTC via flawed transfer
- Buyer suffers $297k effective loss

Recommended Mitigation

Purchase Freeze Lock Implementation

Temporarily block order modifications during buy transactions by setting a "locked" flag when purchases begin, preventing front-running attacks.

// Add to contract state
mapping(uint256 => bool) public orderLocked;
​
// Modified buyOrder function
function buyOrder(uint256 _orderId) public {
Order storage order = orders[_orderId];
// 1. LOCK the order FIRST (before any state changes)
orderLocked[_orderId] = true;
// 2. Execute trade logic
order.isActive = false;
uint256 protocolFee = (order.priceInUSDC * FEE) / PRECISION;
iUSDC.safeTransferFrom(msg.sender, order.seller, order.priceInUSDC - protocolFee);
IERC20(order.tokenToSell).safeTransfer(msg.sender, order.amountToSell);
// 3. UNLOCK after all transfers complete
orderLocked[_orderId] = false;
}
​
// Updated amendSellOrder (now fails if order is being bought)
function amendSellOrder(...) public {
require(!orderLocked[_orderId], "Order currently being executed");
// ... rest of amendment logic ...
}
Updates

Lead Judging Commences

yeahchibyke Lead Judge about 1 month ago
Submission Judgement Published
Validated
Assigned finding tags:

Buy orders can be front-run and amended maliciously

A malicious seller can front-run a buy order for their order, and decrease the amount of assets to be sold. If the price is unchanged, the buy transaction fulfills, but the buyer gets lesser amount than expected.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.