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.