You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 12, 2025. It is now read-only.
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
Since there is no minimum staking time, the reward mechanism can be gamed to drain the rewards from the contract as soon as they are added.
Vulnerability Detail
Any added reward can be drained as soon as they are added to the contract, given that there is no minimum lock time. Because of this, any attacker could easily front-run the reward transfer to create a position with a significant amount of tokens locked, harvest the rewards and then withdraw the tokens from the pool.
Impact
The described behavior will allow any user to drain the rewards, stealing them from the legitimate user's portion.
0xSmartContract
added
Medium
A Medium severity issue.
Duplicate
A valid issue that is a duplicate of an issue with `Has Duplicates` label
and removed
Excluded
Excluded by the judge without consulting the protocol or the senior
labels
Jul 27, 2024
sherlock-admin4
changed the title
Huge Banana Swan - MlumStaking rewards can be drained
sh0velware - MlumStaking rewards can be drained
Jul 29, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelMediumA Medium severity issue.RewardA payout will be made for this issue
sh0velware
High
MlumStaking rewards can be drained
Summary
Since there is no minimum staking time, the reward mechanism can be gamed to drain the rewards from the contract as soon as they are added.
Vulnerability Detail
Any added reward can be drained as soon as they are added to the contract, given that there is no minimum lock time. Because of this, any attacker could easily front-run the reward transfer to create a position with a significant amount of tokens locked, harvest the rewards and then withdraw the tokens from the pool.
Impact
The described behavior will allow any user to drain the rewards, stealing them from the legitimate user's portion.
Code Snippet
https://github.com/sherlock-audit/2024-06-magicsea/blob/main/magicsea-staking/src/MlumStaking.sol#L677-L678
Tool used
Manual Review
PoC:
Recommendation
A minimum locking time should be defined, so the positions are eligible to claim rewards.
Duplicate of #74
The text was updated successfully, but these errors were encountered: