The scheduleEmergencyAction() function allows the admin to input any actionId, but the withEmergencyDelay modifier only works with specific pre-defined action IDs (EMERGENCY_WITHDRAW_ACTION, EMERGENCY_UNLOCK_ACTION).
This creates a potential issue where the admin may mistakenly schedule an invalid actionId that can never be executed, leading to locked emergency actions that cannot be undone.
Admin Can Schedule Any actionId
The function accepts any bytes32 actionId and stores it in _emergencyTimelock.
There is no validation to ensure the actionId matches the predefined emergency actions (EMERGENCY_WITHDRAW_ACTION or EMERGENCY_UNLOCK_ACTION).
If the admin accidentally enters an incorrect actionId, the system will store it but never allow execution.
withEmergencyDelay Only Allows Predefined actionId Values.
This modifier is only applied in two functions:
Problem
If an incorrect actionId is scheduled, it can never be executed because no function calls withEmergencyDelay(actionId).
The wrong actionId will remain stored in _emergencyTimelock indefinitely, leading to admin confusion and potential governance failures.
Incorrect actionId entries remain in _emergencyTimelock indefinitely, causing admin confusion.
If the admin assumes an incorrect action was scheduled properly, they may fail to execute a critical emergency action when needed.
Storing unused actionId entries wastes contract storage.
Manual review
Validate actionId in scheduleEmergencyAction()
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.