Navigating to M-05 from the previous contest we can see that there is a vulnerability in the StRSR contract's unstaking mechanism, where canceled withdrawals can still impact future withdrawal requests. This occurs because the availableAt timestamp of canceled withdrawals is still considered when determining the availability of new withdrawals. As a result, if the unstakingDelay is decreased, users who have previously unstaked would have to wait longer than the current unstakingDelay to withdraw their stake. This situation is completely unfair to users and can even lead to unexpected losses in $ value due to the extra delays in withdrawals. The recommended mitigation is to modify the pushDraft function to ignore the availableAt of canceled withdrawals when determining the availability of new withdrawals, or to allow users to use the current delay even if it was previously higher.
which has been sufficiently mitigated in the pull request used to solve this, i.e:
Lines of code
Vulnerability details
See:
Navigating to M-05 from the previous contest we can see that there is a vulnerability in the
StRSR
contract's unstaking mechanism, where canceled withdrawals can still impact future withdrawal requests. This occurs because theavailableAt
timestamp of canceled withdrawals is still considered when determining the availability of new withdrawals. As a result, if theunstakingDelay
is decreased, users who have previously unstaked would have to wait longer than the currentunstakingDelay
to withdraw their stake. This situation is completely unfair to users and can even lead to unexpected losses in$
value due to the extra delays in withdrawals. The recommended mitigation is to modify the pushDraft function to ignore theavailableAt
of canceled withdrawals when determining the availability of new withdrawals, or to allow users to use the current delay even if it was previously higher.which has been sufficiently mitigated in the pull request used to solve this, i.e: