This audit identifies a critical vulnerability in the _handleTokenOperations
function, where the contract assumes a 1:1 conversion from the collateral token to wToken when interacting with Aave. This assumption is flawed, as Aave’s interest accrual, fees, and dynamic liquidity conditions can introduce slippage. An attacker can exploit this by front-running transactions, manipulating exchange rates, and causing unexpected losses to users.
Issue: Lack of Slippage Protection
The contract does not verify the amount of wTokens received after supplying collateral to Aave.
Aave’s dynamic market conditions (liquidity changes, accrued interest, fees) may lead to variable exchange rates.
An attacker can front-run transactions by supplying or withdrawing funds right before execution, manipulating the exchange rate.
This results in users receiving fewer wTokens than expected, leading to losses.
Example Attack Scenario
Victim initiates a transaction to deposit 1,000 USDC into Aave via _handleTokenOperations.
Attacker detects the transaction and front-runs it by depositing a large sum (e.g., 10M USDC) into Aave.
This dilutes the exchange rate, causing the victim to receive fewer wTokens.
The attacker withdraws their funds immediately, restoring the exchange rate after exploiting the victim
Financial Loss: Users may receive fewer wTokens than expected, reducing their effective collateral.
Front-Running Risk: Attackers can manipulate liquidity conditions, exploiting timing gaps in transaction execution.
Manual
Implement Slippage Protection
Solution: Slippage Tolerance Parameter
· Introduce a minWTokenReceived parameter in _handleTokenOperations
.
· Before executing the transaction, verify that the received wTokens meet or exceed the user’s expectation.
· If the received wTokens are less than the minimum specified, revert the transaction.
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.