Summary

In the Fees.sol contract there is no slippage protection in the swapping function which can result in the protocol receiving fewer tokens than at a fair market price, if a sandwich attack is performed.

Vulnerability Details

In the Fees.sol contract there is no slippage protection in the swapping function which can result in the protocol receiving fewer tokens than at a fair market price, if a sandwich attack is performed. A Sandwich attack is when a bot places a buy order in front of a user’s transaction and a sell order directly after the user’s transaction. So, The user’s order is executed at a higher price and the bot then immediately sells into this price.

I have set the severity of this vulnerability as high, as the Fees.sol contract will be used to swap all of the ERC20 tokens received as fees from the Lender.sol protocol to WETH (otherwise there is no purpose for this contract, and yet the contract itself is vulnerable). Which results in the protocol using funds, not a user of the protocol. This is a different issue than my other issue describing how because the Uniswap V3 router is not approved to spend any ERC20 tokens, thus tokens will be locked forever, as the root of the vulnerability is different - amountOutMinimum: 0, // @audit min return 0 tokens; no slippage => user loss of funds.

Impact

Swaps can happen at a bad price and lead to receiving fewer tokens than at a fair market price. The attacker's profit is the protocol's loss.

Tools Used

Manual Review

Recommendations

Per Uniswap docs amountOutMinimum: For a real deployment, this value should be calculated using our SDK or an onchain price oracle - this helps protect against getting an unusually bad price for a trade due to a front running sandwich or another type of price manipulation.