The LSTRewardsSplitter::performUpkeep function lacks proper access control, allowing any user to call the function. This opens up a vulnerability where an attacker can grief a fee receiver by frontrunning the owner's addFee transaction, causing the fee receiver to miss out on rewards. The function is intended for use by specific users, but since anyone can call it, the attacker can manipulate the reward distribution process to the detriment of the receiver and against the desires of the contract owner.
The performUpkeep function in the LSTRewardsSplitter contract is publicly accessible, meaning any external user can call it. Here’s the function:
If an attacker frontruns an addFee transaction by the owner, they can call performUpkeep just before the owner adds a new fee receiver via addFee:
By calling performUpkeep before the owner can add a new fee, the attacker can split the rewards before the new fee receiver is included. As a result, the new fee receiver misses out on rewards for that upkeep cycle, contrary to the intentions of the contract owner.
An attacker can manipulate the reward distribution process by frontrunning the owner's addFee transaction, causing the new fee receiver to miss out on rewards. This undermines the fairness of the reward distribution process and can lead to financial losses for the fee receiver.
Manual
Add Access Control to performUpkeep: Restrict the ability to call performUpkeep to only authorized users, such as the contract owner or a designated keeper. This will prevent unauthorized users from interfering with the reward distribution process.
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.