SC10—Proxy & Upgradeability Vulnerabilities
>Control Description
Proxy and upgradeability vulnerabilities occur when smart contracts implementing upgradeable architectures have misdesigned or misconfigured upgrade paths, initialization, or admin controls. These systems separate a proxy (holding state and delegating calls) from an implementation (containing logic). When improperly secured, attackers can hijack proxy admin roles, deploy malicious implementations, re-initialize contracts to seize ownership, or bypass initialization checks.
Common patterns include Transparent Proxy, UUPS (EIP-1822), Beacon Proxy, and custom router-implementation designs. Non-EVM chains face analogous risks through mechanisms like Move modules and Solana program upgrades.
**Key Focus Areas:**
- Upgrade and admin roles: control over implementation changes and storage layout compatibility
- Initialization and re-initialization: unprotected initialize functions, missing initializer guards, storage collisions
- Proxy delegation: delegatecall context, msg.sender/msg.value propagation
- Storage layout: slot collisions between proxy and implementation, append-only storage requirements
- Timelocks and governance: upgrade processes and rollback capabilities
**Exploitation Methods:**
- Unprotected upgrade functions allowing any caller to redirect proxies to malicious implementations
- Re-initialization to reset ownership, configuration, or access controls
- Initialization through delegatecall where implementations can be initialized with attacker parameters
- Storage collision between proxy and implementation causing data overwrites
>Prevention & Mitigation Strategies
- 1.Employ well-established proxy patterns and libraries (e.g., OpenZeppelin UUPS/transparent proxies) instead of custom designs.
- 2.Restrict upgrade and admin roles with robust governance mechanisms or multisigs; never rely solely on EOAs without strong operational controls.
- 3.Correctly apply initializer and reinitializer modifiers; lock implementation contracts once deployed to prevent direct initialization.
- 4.Require timelocks and multi-step processes for all upgrades; announce upgrade proposals allowing review time before execution.
- 5.Create comprehensive upgrade runbooks and checklists including migration testing, new implementation code verification, storage layout validation, and on-chain upgrade step simulation.
>Attack Scenarios
#1Kinto Protocol (July 2025, $1.55M loss)
Attackers exploited uninitialized ERC1967 proxy contracts. They detected freshly deployed proxy contracts that had not been properly initialized, then initialized them with malicious implementations containing dormant backdoors.
#2Uninitialized Proxy Campaign (2025, $10M+ across protocols)
A broader campaign targeted uninitialized ERC1967 proxies across multiple EVM chains. Attackers used automated scanning to detect newly deployed proxies before legitimate developers could initialize them, then initialized with malicious implementations. The backdoors remained dormant for months before activation, allowing attackers to upgrade proxies and drain funds.
>References
Ask AI
Configure your API key to use AI features.