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.