The Fees contract sets the sqrtPriceLimitX96 parameter to 0 in the Uniswap V3 swap operation, which makes the contract potentially susceptible to sandwich attacks.
Uniswap V3 introduced a concentrated liquidity model which provides the ability to limit slippage by setting the sqrtPriceLimitX96 parameter. This parameter defines a price limit for a swap and prevents the trade from pushing the pool's price beyond this limit, for additional information you can check this [source](Source: https://ethereum.stackexchange.com/questions/121178/how-to-trade-directly-with-uniswap-v3-pool-instead-of-through-router
) However, in the sellProfits() function of the Fees contract, sqrtPriceLimitX96 is hardcoded to 0 at L39 of Fees.sol:
Exarcebating this issue is the fact that the amountOutMinimum has also being hardcoded, however though being similar this report is not aimed at being a duplicate of the other report submitted by me on the slippage issue of having no specified amountOutMinimum. Additionally, from all this it'd be key to note that hardcoding sqrtPriceLimitX96 to 0 in a swap transaction essentially removes any limit on price slippage. This can lead to different attacks one in which an attacker could even try to backrun a transaction, and cause a user financial loss
Already explained in Vulnerability Details, but to reiterate my point this easily causes financial losses for users
Manual Audit
Allow users to set the sqrtPriceLimitX96 parameter to mitigate this.
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.