Liquid Staking

Summary

The executeQueuedWithdrawals function in PriorityPool.sol lacks a crucial validation check for the pool’s status. This omission allows withdrawals to be processed even when the pool is in a CLOSED state, which contradicts the intended behavior outlined in the documentation.

Vulnerability Details

The function does not include a check to verify the current status of the pool before proceeding with withdrawal operations. Specifically, it does not ensure that the pool is not in a CLOSED state before executing the withdrawal logic, allowing withdrawals to proceed when they should be restricted.

Impact

The absence of this validation allows execution of queued withdrawals even when the pool status is CLOSED—a state that, according to the documentation, should restrict both deposits and withdrawals. This vulnerability could lead to unauthorized withdrawals, potentially disrupting the intended functionality of the protocol during critical periods.

Proof Of Concept

1. Assumes that the PriorityPool has been set to the CLOSED status (poolStatus = 2), where withdrawals should normally be disabled.

2. Since the PriorityPool contract does not check the poolStatus before allowing the withdrawal, the executeQueuedWithdrawals function proceeds without reverting.

3. The executeQueuedWithdrawals will bypass the CLOSED state and will be successfully executed.

Tools Used

Manual review

Recommendations

Introduce a status check at the beginning of the executeQueuedWithdrawals function to ensure that queued withdrawals cannot be executed when the pool is in a CLOSED state:

This check will ensure that withdrawals are correctly restricted when the pool is closed, aligning the contract’s behavior with the documented specifications.