Aave DIVA Wrapper

Summary

A front-running risk was identified in how allowance updates are handled, particularly in cases where approval is increased without resetting it to zero first. This vulnerability could allow an attacker to exploit a race condition, leading to unauthorized token transfers.

https://github.com/Cyfrin/2025-01-diva/blob/1b6543768c341c2334cdff87b6dd627ee2f62c89/contracts/src/AaveDIVAWrapperCore.sol#L363-L367

Vulnerability Details

Description

The _approveCollateralTokenForAave() function currently utilizes safeIncreaseAllowance(), which operates in two distinct steps:

1. Reads the existing allowance.

2. Calculates and sets a new allowance value.

If an attacker front-runs the transaction and spends the allowance before the second step completes, the final allowance value will be incorrect, leading to unintended approvals.

Attack Execution (Step-by-Step)

1. The contract has an existing allowance of 50 tokens.

2. It calls safeIncreaseAllowance(spender, 100), intending to set the allowance to 150.

3. An attacker monitors the transaction in the mempool and quickly spends the 50 allowance before the contract updates it.

4. The contract executes the update but now sees 0 allowance, so it incorrectly increases from 0 to 100 instead of the expected 150.

Impact

· An attacker can drain the contract’s funds by repeatedly front-running approvals.

· The smart contract ends up with incorrect token approvals, potentially exposing it to further exploits.

· Users may experience financial losses as a result of incorrect balances and approvals.

Tools Used

Manual

Recommendations

Instead of using safeIncreaseAllowance() use the safeApprove() , always reset to zero first before setting the new allowance.

Why This Works?
• Resets the old allowance to zero, preventing front-runners from exploiting partial updates.
• Ensures that the final allowance is always correct, regardless of concurrent transactions.
• Eliminates race conditions that arise from sequential approval logic.