Aave DIVA Wrapper

01. Relevant GitHub Links

• https://github.com/Cyfrin/2025-01-diva/blob/23cdc88da7e2a9341f453854e876eee82a18e53e/contracts/src/AaveDIVAWrapperCore.sol#L37C1-L39C1

• https://github.com/Cyfrin/2025-01-diva/blob/23cdc88da7e2a9341f453854e876eee82a18e53e/contracts/src/AaveDIVAWrapperCore.sol#L60C1-L62C1

02. Summary

The AaveDIVAWrapper contract defines several critical variables—particularly _diva, _aaveV3Pool, and mappings like _collateralTokenToWToken—which are only set once. There are no functions allowing the contract owner (or any other entity) to either update or remove these references. Consequently, if a collateral token turns out to be invalid, deprecated, or otherwise compromised, there is no mechanism to delete it. Similarly, if _diva or _aaveV3Pool addresses need to change (e.g., due to upgrades or identified security issues), there is no built-in function to facilitate this.

03. Vulnerability Details

• Irremovable Collateral Tokens

Mappings such as:

are set using registerCollateralToken but lack any function to remove a registered collateral token. This means if a token is mistakenly added or later becomes unsafe, there is no direct way to unregister or replace it.

• Immutable Core Addresses

The constructor sets _diva and _aaveV3Pool once:

No function exists to update these addresses. If _diva or _aaveV3Pool need to change for any reason (e.g., contract upgrades, identified vulnerabilities, or protocol migrations), there is no built-in flexibility to do so.

This design choice appears to prioritize simplicity and trust that the initially set addresses will remain valid indefinitely. However, in decentralized finance (DeFi), protocol upgrades or the need to deprecate certain tokens are relatively common. A complete lack of update/removal mechanisms can hinder the protocol’s ability to adapt and mitigate unforeseen issues.

04. Impact

Operational Risk: If the registered collateral token becomes deprecated or if there is a security flaw with the token contract, the AaveDIVAWrapper contract cannot remove or replace it. This may force the entire system to rely on an unsafe or useless token indefinitely or require a full contract migration.

05. Tools Used

Manual Code Review and Foundry

06. Recommended Mitigation

• Implement a function (restricted to the contract owner) allowing the removal of any collateral token from _collateralTokenToWToken and _wTokenToCollateralToken. This ensures that invalid or compromised tokens can be deprecated.

• Provide functions to update _diva and _aaveV3Pool if necessary. These can be restricted through onlyOwner or a more robust governance mechanism to prevent unauthorized changes.