The transferReward function allows an attacker to transfer rewards indefinitely, filling the rewardsOwned array of a victim with default or "ghost" rewards. This could potentially lead to a Denial of Service (DoS) if future functions iterate over this array or depend on its size for processing.
The delete keyword in Solidity sets the value of the element to its default value, which does not remove the item from the array but sets it to a zero value. Over time, this can lead to the accumulation of "ghost" rewards in the victim's rewardsOwned array.
There is no limit to how many times transferReward can be called. An attacker could repeatedly transfer rewards to the victim, bloating the array with zero-value elements. This could impact future contract functionality or degrade performance if any iteration or size-based operations are introduced.
This test demonstrates how an attacker can exploit the transferReward function to perform a Denial of Service attack by filling the victim's rewardsOwned array with zero-value rewards.
Medium/High Impact: An attacker could potentially perform a DoS attack by filling the victim's rewardsOwned array with zero-value rewards. If future functions iterate over this array, it would degrade the performance or even cause the contract to run out of gas.
Manual code review.
Foundry testing framework.
Limit the number of transfers: Set a maximum limit on the size of the rewardsOwned array or restrict how many times a user can call transferReward in a certain period.
Properly remove rewards: Use array resizing instead of delete to prevent the accumulation of "ghost" rewards in the array. Replace the element being deleted with the last element and reduce the array size:
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.