Core Contracts

Summary

The executeEmergencyAction function does not enforce any delay check before executing emergency operations. Although an EMERGENCY_DELAY constant (set to 1 day) exists, it is never used in the emergency execution logic. This allows addresses with the EMERGENCY_ROLE to execute emergency actions immediately after scheduling, without waiting for the intended timelock period.

Impact

Immediate execution of emergency actions bypasses the core security mechanism of the timelock, which is designed to give stakeholders time to review and potentially contest changes. As a result, a malicious or compromised EMERGENCY_ROLE account could trigger arbitrary, potentially harmful actions without any delay, undermining the protocol’s security and governance.

Vulnerability Details

The root cause is that the emergency execution function does not incorporate the EMERGENCY_DELAY in its conditions. While normal operations have enforced delays through timestamps and grace periods, the executeEmergencyAction function solely relies on the pre-scheduling via scheduleEmergencyAction and does not check if the current time meets any delay requirement.

For example, assume the protocol intends that any emergency action must be delayed by at least 1 day after scheduling. If a malicious actor with the EMERGENCY_ROLE schedules an emergency action at T = 0 and immediately calls executeEmergencyAction at T = 1 minute, the operation will execute without waiting the intended 24 hours. This rapid execution could allow the actor to, for instance, transfer large sums of tokens or change critical parameters instantly, bypassing community oversight.

Recommendations

Modify the executeEmergencyAction function to include a check that ensures the current time is at least EMERGENCY_DELAY after the emergency action was scheduled. For instance, store the scheduling timestamp and require that:

require(block.timestamp >= scheduledTimestamp + EMERGENCY_DELAY, "Emergency delay not met");