The buy
function in the Auction
contract lacks slippage protection, exposing users to potential overpayment due to price fluctuations. This issue enables front-running attacks where an attacker can manipulate the price before a transaction is executed, leading to unfair pricing for the buyer an DoS.
The following code snippet highlights the vulnerability:
The function fetches the current price from getPrice()
, but since getPrice()
is time-dependent, the price may change within the same block due to network congestion or market conditions. A front-running bot can detect a purchase and manipulate the price before the user's transaction is executed.
Scenario:
User submits a transaction to buy 100 ZENO
tokens at a price of 100 USDC per token
.
Before the transaction is confirmed, an attacker detects it and places a small buy order, increasing the price to 120 USDC per token
.
The user's transaction executes at the higher price, costing them more than expected.
In Auction
contract we have function getPrice
where user can check price, but anyway malitious user can change price exactly after user send tx to buy ZENO tokens and front-run it.
Test:
Output:
Error: Transaction reverted: Price too high
Users may end up overpaying for tokens due to price manipulation.
Front-running bots can take advantage of price changes, leading to unfair auctions.
If the user on his wallet has the same amount as he send to function buy
and the attacker or regular user inflates the price, tx will revert.
Manual review.
Implement a slippage tolerance mechanism where the user specifies a maximum acceptable price:
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.