and posKey is assigned as encodePosKey(owner, poolIdx, lowerTick, upperTick), in which lowerTick and upperTick is passed in by user.
However, in the whole workflow of claimConcentratedRewards, accrueConcentratedPositionTimeWeightedLiquidity can only accrues the in-range time-weighted concentrated liquidity for a position by going over the tick entry / exit history, so different lowerTick and upperTick(be a superset of the limit) can request for reward many times.
Lines of code
https://github.com/code-423n4/2023-10-canto/blob/main/canto_ambient/contracts/mixins/LiquidityMining.sol#L177-L180
Vulnerability details
Impact
Function
claimConcentratedRewards
has insufficient inspection of whether an user has claimed reward for a week.Proof of Concept
Function
claimConcentratedRewards
use the following code to check whether the reward has been repeatedly claimed:and
posKey
is assigned asencodePosKey(owner, poolIdx, lowerTick, upperTick)
, in which lowerTick and upperTick is passed in by user. However, in the whole workflow ofclaimConcentratedRewards
,accrueConcentratedPositionTimeWeightedLiquidity
can only accrues the in-range time-weighted concentrated liquidity for a position by going over the tick entry / exit history, so different lowerTick and upperTick(be a superset of the limit) can request for reward many times.Tools Used
Mannual review
Recommended Mitigation Steps
use
owner
instead ofposKey
in the checkAssessed type
Invalid Validation