Core Contracts

The function notifyRewardAmount(uint256 amount) updates the rewardRate based on a new reward allocation but does not properly reset rewardPerTokenStored before doing so. This creates a race condition where an attacker can front-run the reward notification and claim an unfairly large portion of the rewards. The vulnerability arises because earned(address account) relies on rewardPerTokenStored, which is calculated using getRewardPerToken(). When notifyRewardAmount() is called, it increases the reward rate, and since rewardPerTokenStored is not reset immediately, an attacker who has recently claimed can quickly call getReward() again before other users, benefiting from the inflated rewards. This allows the attacker to extract excess funds at the expense of other participants. The faulty implementation in notifyRewardAmount() is as follows:

The function increases the reward rate before ensuring all stakers' reward states are updated. Consequently, attackers who recently claimed rewards can quickly claim again before the recalculations propagate correctly.

Impact

Attackers can unfairly drain the reward pool by claiming excess rewards before other participants, leading to significant fund depletion.

Mitigation

Modify notifyRewardAmount() to call _updateReward(address(0)) before modifying rewardRate to ensure all users' rewards are updated before new rewards are distributed.