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
The claimWithdrawal function allows immediate withdrawal after the lock period ends. A malicious actor could manipulate the timing to front-run legitimate withdrawals
Internal pre-conditions
The withdrawal lock period is hardcoded
A malicious actor knows exactly when the lock expires
External pre-conditions
The attacker can manipulate block timing’s to front-run legitimate users
Attack Path
The attacker monitors the block timing and initiates a withdrawal as soon as the lock expires
They drain the funds before legitimate users can react
Impact
Users lose their staked funds as the attacker front-runs the withdrawal process. For example, if the total stake is 1000 ETH, the attacker could withdraw all funds before others
PoC
No response
Mitigation
Implement a randomised delay or use a time stamp-based lock rather than block-based timing to reduce predictability
The text was updated successfully, but these errors were encountered:
sherlock-admin3
changed the title
Kind Coconut Crane - Unrestricted withdrawal mechanism
Rea - Unrestricted withdrawal mechanism
Oct 16, 2024
Rea
Medium
Unrestricted withdrawal mechanism
Summary
The claimWithdrawl function allows a staker to withdraw funds immediately after the withdrawal lock period ends, but the lock period is hardcoded
Line of code
https://github.com/sherlock-audit/2024-08-morphl2/blob/main/morph/contracts/contracts/l1/staking/L1Staking.sol#L307
Root Cause
The claimWithdrawal function allows immediate withdrawal after the lock period ends. A malicious actor could manipulate the timing to front-run legitimate withdrawals
Internal pre-conditions
External pre-conditions
Attack Path
Impact
Users lose their staked funds as the attacker front-runs the withdrawal process. For example, if the total stake is 1000 ETH, the attacker could withdraw all funds before others
PoC
No response
Mitigation
Implement a randomised delay or use a time stamp-based lock rather than block-based timing to reduce predictability
The text was updated successfully, but these errors were encountered: