Aave DIVA Wrapper

Description:
The functions approveCollateralTokenForAave and batchApproveCollateralTokenForAave lack the onlyOwner access control modifier. This allows any user to call these functions and approve arbitrary collateral tokens for Aave V3, even if the tokens are already registered. While the internal _approveCollateralTokenForAave function checks that the collateral token is registered, it does not restrict who can trigger the approval. This creates a significant security risk, as malicious actors can exploit this to reset or increase approvals for registered tokens, potentially draining funds if Aave V3 is compromised.

impact:

1. Funds Theft: Attackers can reset or increase approvals for registered tokens, enabling them to drain funds from the contract if Aave V3 is exploited

2. Protocol Dependency Risk: The security of AaveDIVAWrapper is directly tied to the security of Aave V3, and unauthorized approvals increase the attack surface.

3. Bypassing Owner’s Intent: The owner’s intended approval limits can be overridden by attackers, leading to unexpected behavior.

Proof of Concept:

Attack Scenario:
The owner registers a collateral token (e.g., USDC) and sets a limited approval (e.g., 100 USDC).

An attacker calls approveCollateralTokenForAave to reset the approval to type(uint256).max.

If Aave V3 is compromised, the attacker can drain all USDC from the contract.

The check _collateralTokenToWToken[_collateralToken] != address(0) only verifies registration, not caller permissions.

Recomended Mitigation:

1. Implement the onlyOwner access control modifier in approveCollateralTokenForAave and batchApproveCollateralTokenForAave.