Core Contracts

Summary

Both regular and emergency operations use the same ID generation logic but are stored in separate mappings (_operations and _emergencyActions). This allows An operation to exist simultaneously in both mappings.

1. The same transaction batch to be executed twice:

   • Once via executeEmergencyAction (immediately, bypassing timelock)

   • Again via executeBatch (after timelock delay)

Vulnerability Details

Step-by-Step Exploit

1. Create Colliding ID:
   Proposer creates a regular operation with parameters (targets, values, calldatas, salt), generating ID X.

2. Schedule Emergency Action:
   Emergency role schedules an emergency action with the same parameters, reusing ID X.

3. Execute via Emergency:

Execute via Regular:
After timelock delay:

executeEmergencyAction doesn't check regular operations and executeBatch doesn't check emergency actions

Impact

If the operation sends 100 ETH to an address:

Attacker executes it twice, draining 200 ETH instead of 100 ETH.

Tools Used

Foundry

Recommendations

Add a type discriminator to the ID hashing to prevent collisions