The executeEmergencyUnlock
function forces the contract into an emergency state by setting emergencyUnlockEnabled = true
without any method to revert it to false
, creating a permanently unlocked system if triggered even once.
This function’s design breaks the guarantee emergency conditions last only as long as needed. By allowing the owner to call executeEmergencyUnlock()
and never supplying a way to revert to a normal state, the contract remains in perpetual emergency mode.
If the owner makes an erroneous call, the system permanently bypasses all normal restrictions or lock durations. This flaw hinges on a single function call that toggles a state variable without an option to restore normal operation. Such an unstoppable unlock invites indefinite risk, as all users can withdraw locked tokens prematurely once the system is declared in emergency mode.
After an owner (or compromised key) invokes the function, no reversion is possible. This undermines the lock-based constraints, enabling everyone to withdraw early and destroying the original economic design. I'm rating this as a Medium because it does not directly grant an attacker new tokens or collateral but disrupts the fundamental lock mechanics. The exploit though, has a High likelihood if the contract’s owner can easily call executeEmergencyUnlock()
at any time.
Manual Review
Implement a simple function—like disableEmergencyUnlock()
—that an authorized address can call once the crisis is resolved:
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.