# openzeppelin initializable with initializer modifier prevents re-initialization attacks on proxy contracts The `initializer` modifier from OpenZeppelin's `Initializable` contract tracks whether initialization has occurred and reverts on subsequent calls, addressing [[uninitialized proxy contracts are vulnerable to re-initialization attacks that hijack ownership|the re-initialization attack]]. It sets a boolean flag in a reserved storage slot persisting across delegatecall contexts (since [[delegatecall executes code from another contract using the callers storage context|delegatecall preserves the caller's storage]], the flag lives in proxy storage). The `reinitializer(n)` variant allows controlled sequential initialization for upgrades. The [[parity wallet hack demonstrated that selfdestruct in implementation contracts permanently bricks proxy systems|Parity wallet incident]] (~$280M frozen at the time, 513,774 ETH) is the canonical case where this defense was absent. **Important limitation:** The modifier does not prevent CPIMP attacks occurring before initialization runs. Since [[non-atomic proxy deployment creates a front-running window where any actor can write to the ERC1967 implementation storage slot before the legitimate initialization transaction confirms]], an attacker can write a shadow implementation before the legitimate initialization confirms; the modifier never executes because the shadow intercepts first. The guard prevents re-initialization after deployment; [[atomic proxy deployment by passing initialization data to the ERC1967Proxy constructor eliminates the CPIMP front-running window because deployment and initialization occur within a single transaction]] prevents pre-initialization attacks. They are complementary defenses. --- Relevant Notes: - [[uninitialized proxy contracts are vulnerable to re-initialization attacks that hijack ownership]]: the attack this prevents - [[parity wallet hack demonstrated that selfdestruct in implementation contracts permanently bricks proxy systems]]: the canonical exploit of missing initialization guards - [[delegatecall executes code from another contract using the callers storage context]]: the mechanism requiring proxy-side initialization - [[vyper module composition uses explicit uses initializes and exports keywords preventing accidental state coupling between modules]]: Vyper's language-level alternative: the `initializes` keyword enforces exactly-once module initialization without requiring library-level guards - [[non-atomic proxy deployment creates a front-running window where any actor can write to the ERC1967 implementation storage slot before the legitimate initialization transaction confirms]]: the vulnerability the `initializer` modifier does NOT prevent; requires atomic deployment as the defense - [[atomic proxy deployment by passing initialization data to the ERC1967Proxy constructor eliminates the CPIMP front-running window because deployment and initialization occur within a single transaction]]: the complementary defense that addresses the pre-initialization phase this modifier cannot cover Topics: - [[security-patterns]]