๐ YESTERDAY'S BUG โ REVEALED.
The vulnerability line is the unbounded external call loop:
for (uint i = 0; i < stakingPools.length; i ) {
IPool(stakingPools[i]).emergencyExit(msg.sender);
}
Two exploitable problems here:
PROBLEM 1 โ Denial of Service.
If stakingPools grows large enough, the gas required to iterate the entire array exceeds the block gas limit. emergencyWithdraw() permanently reverts for everyone. In a genuine emergency โ when this function matters most โ it becomes completely uncallable. Funds are permanently locked.
PROBLEM 2 โ Malicious pool griefing.
If any single IPool in the array has a broken or malicious emergencyExit() that reverts โ it causes the entire transaction to revert. One bad pool entry blocks every user from emergency withdrawing. Funds are locked until the bad pool is somehow removed.
The root cause: the ETH transfer to the user is at the END of the function, after all external calls complete. If any external call fails, the user loses both their staked position AND their ETH โ temporarily if revert restores state, but permanently if the revert condition is unresolvable.
FIXED FUNCTION: ๐
Emergency functions must be gas-efficient and failure-resistant. When users need them, everything else is already wrong.
๐ด SPOT THE BUG #7 โ Emergency withdrawal function. One line enables theft.
Which line creates the vulnerability โ and how would you exploit it?
Drop your answer๐ Answer in 24 hours.