is missing the case where the incentive might be a pre-existing clone rather than a base implementation that needs to be cloned.
The bug is that it's always treating the incentive as if it needs to be cloned (by passing false as the third argument to _makeTarget), but it should handle both cases:
When the incentive is a base implementation that needs to be cloned
When the incentive is already a clone that just needs to be used as-is
To fix this, we should check the isBase property of the target. Here's the corrected version:
Because shouldInitialize_ is false, the cloned instance is never initialized.
The uninitialized clone is then used as the incentive for the Boost.
This leads to a serious issue where the incentive contract is deployed but not properly initialized, potentially causing unexpected behavior or failures when interacting with the Boost later.
For example, if the incentive has critical parameters that should be set during initialization (like reward amounts or limits), these would remain unset, possibly leading to funds being locked or the incentive not functioning as intended.
Minato7namikazi
High
Incorrect Incentive Initialization in BoostCore!
Summary
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/78930f2ed6570f30e356b5529bd4bcbe5194eb8b/boost-protocol/packages/evm/contracts/BoostCore.sol#L266
The line:
is missing the case where the incentive might be a pre-existing clone rather than a base implementation that needs to be cloned.
The bug is that it's always treating the incentive as if it needs to be cloned (by passing
false
as the third argument to_makeTarget
), but it should handle both cases:To fix this, we should check the
isBase
property of the target. Here's the corrected version:This change ensures that:
targets_[i].isBase
is true, it will clone and initialize the incentive.targets_[i].isBase
is false, it will use the existing instance without cloning.This correction aligns with the project's design of allowing both new clones and pre-existing instances to be used as incentives in a Boost.
The bug can be triggered because:
_makeIncentives
function, there's a check that ensures the target is a base implementation:_makeTarget
always passesfalse
as the third argument:This creates a contradiction: the function requires the target to be a base implementation, but then tells
_makeTarget
not to clone it.Impact and PoC flow:
isBase
to true in theTarget
struct for their incentive.createBoost
function is called, which in turn calls_makeIncentives
._makeIncentives
passes the validity check forisBase
._makeTarget
is called, it receivesfalse
as the third argument._makeTarget
, the_maybeClone
function is called:shouldInitialize_
is false, the cloned instance is never initialized.This leads to a serious issue where the incentive contract is deployed but not properly initialized, potentially causing unexpected behavior or failures when interacting with the Boost later.
For example, if the incentive has critical parameters that should be set during initialization (like reward amounts or limits), these would remain unset, possibly leading to funds being locked or the incentive not functioning as intended.