Critical Severity
Proxy & Storage

DELEGATECALL Vulnerabilities

delegatecall is one of the most powerful — and most dangerous — opcodes in Solidity. It runs external code inside your contract's own storage context. A bug in any library you delegate to is effectively a bug in your contract.

How delegatecall works

Normally, when contract A calls contract B, B's code runs using B's own storage, B's address, and the caller's msg.sender. With delegatecall, B's code runs but everything else belongs to A: A's storage, A's address, A's ETH balance.

This is intentional and useful — it's how proxy contracts work. But it creates a fundamental risk: anything B's code does to "its own" variables actually modifies A's storage slots. If an attacker can influence what B does, they control A.

Critical

User-controlled delegate target

The address passed to delegatecall comes from user input. Attacker supplies their own malicious contract.

Critical

Unprotected initializer

Library or implementation contract has no access control on initialize(). Anyone can call it and become owner.

High

Storage layout mismatch

Proxy and implementation define storage variables in different orders. Write to slot 0 in impl overwrites slot 0 (owner) in proxy.

Critical

Self-destruct in delegate target

Implementation contract contains selfdestruct. If called, it kills the proxy (not the impl), since delegatecall runs in proxy's context.

Real-world exploits

ProtocolYearPatternLoss
Parity Multi-Sig2017Unprotected initializer in shared library$30M frozen forever
Parity Multi-Sig v12017User-controlled delegatecall target$31M drained
Wormhole Bridge2022Delegatecall in guardian verification logic$320M
Ronin Bridge2022Proxy upgrade without sufficient multisig$625M

Scan for delegatecall vulnerabilities

Our scanner checks for user-controlled delegatecall targets, unprotected initializers, storage layout mismatches, and other proxy-related risks.