Liquid Staking

Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Submission Details
Severity: medium
Invalid

Withdrawal Queue:: Exploit Causing Temporary Lockup of Staking Pool

Summary

An attacker can manipulate the deposit and withdrawal mechanisms in the system by continuously filling the withdrawal queue and front-running legitimate deposits. This can cause a temporary lockup of the staking pool by ensuring that all incoming deposits are redirected to fulfill withdrawal requests, preventing users from staking their tokens and earning rewards.

Vulnerability Details

The system prioritizes fulfilling withdrawal requests from the Withdrawal Pool before depositing new tokens into the Staking Pool when there is a withdrawal queue. This behavior can be exploited by an attacker who continuously fills the withdrawal queue and deposits just enough to keep it full, effectively blocking legitimate users from staking their tokens.

  • The attacker submits a large withdrawal request to the Withdrawal Pool (e.g., 200 LINK).

  • Any deposit made afterward by legitimate users (e.g., 100 LINK) will be redirected to fulfill the attacker’s pending withdrawal instead of going into the staking pool.

  • The attacker can then front-run the remaining deposits by depositing a large amount (e.g., 150 LINK) and immediately filling their own withdrawal request.
    Afterward, the attacker submits a new large withdrawal request, repeating the process.

if (totalQueued == 0) {
uint256 queuedWithdrawals = withdrawalPool.getTotalQueuedWithdrawals();
if (queuedWithdrawals != 0) {
uint256 toDepositIntoQueue = toDeposit <= queuedWithdrawals
? toDeposit
: queuedWithdrawals;
withdrawalPool.deposit(toDepositIntoQueue);
toDeposit -= toDepositIntoQueue;
IERC20Upgradeable(address(stakingPool)).safeTransfer(_account, toDepositIntoQueue);
}
}

Any deposits will first go into the withdrawal pool until queued withdrawals are fulfilled. The attacker can exploit this to force all deposits to fill their withdrawal requests before legitimate users can stake.

POC

Assumptions:

  • Withdrawal Queue: Let’s assume there are pending withdrawal requests in the queue totaling 200 LINK, which need to be fulfilled before new deposits go into the staking pool.

  • Staking Pool: Is nearly full or temporarily has limited capacity for deposits.

  • Attacker's Resources: The attacker has enough LINK tokens to keep depositing and withdrawing large amounts.

  1. Initial Setup:

    • There are 200 LINK in the withdrawal queue.

  2. Legitimate Deposit:

    • A legitimate user, User A, deposits 100 LINK.
      The 100 LINK is redirected to the Withdrawal Pool to fulfill part of the 200 LINK withdrawal request. The queue is reduced to 100 LINK.

  3. Attacker's Actions:

    • The attacker then deposits 150 LINK. The first 100 LINK fulfills the remaining withdrawal request. The remaining 50 LINKs either go to the staking pool or are queued if the pool is full.

  4. Attacker Creates a New Withdrawal Request:

    • Immediately after depositing, the attacker creates another 200 LINK withdrawal requests, refilling the withdrawal queue and continuing the lockup.

    • This cycle can be repeated indefinitely, preventing any deposits from entering the staking pool.

Impact

Due to the continuous filling of the withdrawal queue, no deposits from legitimate users will ever reach the staking pool. This leads to a temporary lockup, where users cannot stake their tokens and miss out on rewards.

Tools Used

Manual review

Recommendations

Implement time-based delays or limits on when an account can create a new withdrawal after making a large deposit, preventing immediate refill of the withdrawal queue by the same attacker.

Updates

Lead Judging Commences

inallhonesty Lead Judge
about 1 year ago
inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.