aman - Setting penalty for each month is vulnerable to frontrunning

[sherlock-admin2]

aman

Medium

Setting penalty for each month is vulnerable to frontrunning

Summary

Setting the penalty amount for each month is vulnerable to frontrunning, as the code allows the AIRDROP_PENALTY_OPERATOR_ROLE to adjust the penalty amount for both the current and upcoming months.

Root Cause

https://github.com/sherlock-audit/2024-10-usual-labs-v1/blob/main/pegasus/packages/solidity/src/airdrop/AirdropDistribution.sol#L371

Internal pre-conditions

1. The AIRDROP_PENALTY_OPERATOR_ROLE set the Penalty amount for current month or next month.
2. The Penality amount is increase from the current amount.

External pre-conditions

1. The User either paid Tax or not can frontrun.
2. The User still need to claim his vesting amount for this month.

Attack Path

1. The AIRDROP_PENALTY_OPERATOR_ROLE decide to increase the penalty amount for current month or next month.
2. The user who still need to claim his vesting amount see the transaction of penalty amount increased.
3. The user frontrun the transaction and pay less penalty amount than required.
4. It will effect the current month if user has not paid the Tax other wise it will effect the next month.

Impact

Setting the penaltyAmount each month is vulnerable to frontruning and will result is un faverable amount paid for penality. This can even effect the next month penaltyAmount in case user has paid tax.

PoC

No response

Mitigation

Either Decide the penalty amount for each Month in advance or pause the AirdropDistribution before setting the Penalty and also mention it in Docs.