Smart Contract Security Audit Guide: Deploying Different Contracts to the Same Address

Overview

In Ethereum's ecosystem, deterministic contract address generation offers convenience but introduces unique attack vectors. This article explores how malicious actors exploit CREATE and CREATE2 opcodes to deploy different contracts to identical addresses over time—along with proven defense strategies.

Core Concepts

1. CREATE Opcode

• Purpose: Dynamically deploys smart contracts via EVM.
• Address Generation: Derived from sender's address and nonce (keccak256(RLP(sender, nonce))).
• Non-Deterministic: Cannot predict the address before deployment.

2. CREATE2 Opcode (EIP-1014)

• Purpose: Enables precomputable contract addresses before deployment.
• Address Generation: Uses sender, salt, and init_code hash (keccak256(0xff || sender || salt || keccak256(init_code))).

Address Conflict Rules:

• If the target address exists (EOA or contract), deployment fails.
• Exception: Self-destructed contracts allow redeployment.

Attack Scenario: DAO Governance Exploit

Vulnerable Contract

contract DAO {  
    struct Proposal { address target; bool approved; bool executed; }  
    address public owner = msg.sender;  
    Proposal[] public proposals;  

    function approve(address target) external {  
        require(msg.sender == owner, "Unauthorized");  
        proposals.push(Proposal(target, true, false));  
    }  

    function execute(uint256 proposalId) external payable {  
        Proposal storage proposal = proposals[proposalId];  
        require(proposal.approved && !proposal.executed, "Invalid proposal");  
        proposal.executed = true;  
        (bool ok,) = proposal.target.delegatecall(abi.encodeWithSignature("executeProposal()"));  
        require(ok, "Delegatecall failed");  
    }  
}  

Attack Steps

1. Deploy Legitimate Contract: Attacker deploys benign Proposal contract (Address P).
2. Get Approval: DAO owner approves P.
3. Self-Destruct: Attacker destroys Proposal via selfdestruct.
4. Redeploy Malicious Contract: Using CREATE2, attacker deploys Attack contract to same P.
5. Execute Malicious Code: DAO’s delegatecall runs Attack.executeProposal(), hijacking ownership.

Key Insight: CREATE2’s deterministic address + selfdestruct enables bait-and-switch attacks.

Mitigation Strategies

For Developers

• Code Hash Verification: Store and check extcodehash at approval/execution.
• Avoid delegatecall: Or restrict it to immutable/trusted contracts.
• Monitor Self-Destructs: Assume redeployment risk for critical external calls.

For Auditors

• Check for selfdestruct: Flag contracts allowing destruction.
• Validate CREATE2 Salts: Ensure randomness to prevent address squatting.
• Review delegatecall Targets: Confirm no arbitrary address calls.

👉 Learn more about secure contract design

FAQ

Q1: Can EOA addresses be hijacked via CREATE2?
A1: No—CREATE2 only affects contract accounts. EOAs remain secure.

Q2: How does extcodehash prevent attacks?
A2: It captures bytecode fingerprints, detecting redeployments.

Q3: Is CREATE2 inherently unsafe?
A3: No, but misuse (e.g., predictable salts) creates risks.

👉 Explore advanced security audits

Disclaimer: This content is educational only. Always conduct independent audits before deployment.

### SEO Keywords  
1. Smart Contract Security  
2. CREATE2 Attack  
3. Delegatecall Vulnerability  
4. Ethereum Address Hijacking  
5. Code Hash Verification  
6. Self-Destruct Mitigation  
7. DAO Governance Risks