# restricting delegatecall to pre-verified logic contracts prevents arbitrary code execution Maintaining an allowlist of verified implementation addresses and checking targets against it before delegatecall prevents the [[unrestricted delegatecall allowing user-specified target addresses enables fund drainage and state manipulation|unrestricted delegatecall vulnerability class]]. The [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation|Furucombo exploit]] ($14M, 2021) is the direct consequence of omitting this check. The allowlist can be implemented as a mapping of approved addresses, a registry contract, or through proxy patterns like UUPS where the implementation itself controls the upgrade function. The key invariant is that no user-supplied address should reach a delegatecall without validation. Since [[delegatecall executes code from another contract using the callers storage context]], an unvalidated target gains full read-write access to all caller state. --- Relevant Notes: - [[unrestricted delegatecall allowing user-specified target addresses enables fund drainage and state manipulation]]: the vulnerability this prevents - [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation]]: the exploit that demonstrates the consequence - [[delegatecall executes code from another contract using the callers storage context]]: the mechanism that makes target validation essential - [[unvalidated user-supplied contract addresses enable arbitrary code execution when protocols call interfaces on attacker-controlled deployments]]: the ordinary-call variant of the same root cause; address verification before dispatch applies equally whether the invocation is delegatecall or interface call Topics: - [[security-patterns]]