Summary
Newly added rewards through the addReward function are not considered as potential reward options in the openBox function, leading to a disconnect between rewards added after contract deployment and the rewards distributed when opening a box.
Vulnerability Details
The issue arises because the openBox function determines rewards based on a random value ranging from 0 to 99. The rewards are pre-defined in the function itself:
- 0-74: Coal Coin (75% chance)
- 75-94: Bronze Coin (20% chance)
- 95-98: Silver Coin (4% chance)
- 99: Gold Coin (1% chance)
However, any rewards added via the addReward function are not integrated into this distribution mechanism. As a result, these newly added rewards cannot be won, making them unusable in practice. Since the reward allocation is hardcoded based on a specific range of random numbers, the additional rewards are never considered by the openBox function, which breaks the intended functionality of allowing dynamic reward updates.
Impact
Rewards added to the rewardPool through the addReward function are ignored when users open boxes, meaning they cannot be won. This could mislead protocol users, as they might assume that newly added rewards will be available as prizes, but in reality, only the original four rewards are distributed.
Tools Used
Recommendations
1. Adjust the openBox Function: Ensure that any newly added rewards are included in the reward selection logic. This can be done by dynamically updating the range of random values used to select rewards based on the contents of the rewardPool.
2. Remove the addReward Function (if not required): If the intention is to limit rewards to those predefined in the constructor, the addReward function should be removed to avoid confusion and unnecessary complexity.