The AaveDIVAWrapper contract incorrectly invokes the AaveDIVAWrapperCore constructor with mismatched parameter ordering. This can lead to the contract being initialized with the wrong addresses for the DIVA Protocol and Aave V3 Pool, potentially causing malfunctions and unexpected behavior.
The vulnerability stems from an inconsistency in how the constructor parameters are ordered between the AaveDIVAWrapperCore contract and the AaveDIVAWrapper contract that inherits from it.
In AaveDIVAWrapperCore.sol, the constructor is defined with the following parameter order:
However, when AaveDIVAWrapper invokes the AaveDIVAWrapperCore constructor in AaveDIVAWrapper.sol, it uses a different parameter order:
As you can see, the _aaveV3Pool and _diva parameters are swapped in the AaveDIVAWrapper constructor compared to the order expected by AaveDIVAWrapperCore.
This mismatch can lead to the AaveDIVAWrapperCore contract being initialized with the wrong addresses. Specifically:
_aaveV3Pool from AaveDIVAWrapper will be assigned to diva_ in AaveDIVAWrapperCore
_diva from AaveDIVAWrapper will be assigned to aaveV3Pool_ in AaveDIVAWrapperCore
Only the _owner parameter is passed correctly due to its position as the last argument in both constructors.
The impact of this vulnerability is that the AaveDIVAWrapperCore contract, which forms the core logic of the system, will be initialized with incorrect addresses for the DIVA Protocol and Aave V3 Pool.
Similarly, when the AaveDIVAWrapperCore contract is set up with the wrong addresses, it might seem to deploy and operate normally at first. But under the hood, it's interacting with the wrong external contracts. This could lead to a range of issues, such as:
Transactions being sent to incorrect destinations
Failures when trying to interact with the intended DIVA Protocol or Aave V3 Pool
Unexpected errors or strange behavior in functions that rely on these external interactions
Potential loss of funds if tokens are mistakenly sent to the wrong places
The exact impact would depend on how the AaveDIVAWrapper is used within the larger system and what capabilities it has. But in a worst-case scenario, this mixup could cause a significant portion of the system to malfunction or produce incorrect results.
The vulnerability was identified through manual code review and analysis. No automated tools were necessary, as the issue is apparent from comparing the constructor parameter ordering in the relevant contracts.
To mitigate this vulnerability, the constructor in AaveDIVAWrapperCore should be updated to match the parameter order used in the AaveDIVAWrapper constructor:
By aligning the parameter order, the AaveDIVAWrapperCore contract will be initialized with the correct addresses when invoked from AaveDIVAWrapper, ensuring the system interacts with the intended external contracts.
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.