The executeEmergencyAction function does not verify whether a specified predecessor operation has been executed before executing the emergency action. In normal operation execution, there is a check to ensure that the predecessor operation is done, but this is omitted in the emergency path.
Without verifying predecessor dependencies, emergency actions may execute out of sequence. This could lead to unintended state changes if an emergency action depends on the successful completion of a previous operation. As a result, the protocol state could become inconsistent or vulnerable.
The root cause is the omission of the predecessor check in the executeEmergencyAction function. The design of the timelock relies on operations being executed in order if dependencies exist, but the emergency action path bypasses this safeguard.
For instance, consider an emergency action that is intended to update a critical parameter but depends on a prior operation that sets up related state variables. If the predecessor operation has not been executed, the emergency action could operate on uninitialized or incorrect data, causing system failures. If the intended predecessor was never executed, the emergency action might execute on a partially configured system, leading to potential fund loss or misallocation.
Add a check in executeEmergencyAction similar to the normal operation execution path. Before executing the emergency action, if a predecessor is specified, require that:
This ensures that emergency actions maintain the correct execution order.
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.