# unrestricted delegatecall allowing user-specified target addresses enables fund drainage and state manipulation When a contract performs a delegatecall to an address supplied by the caller without validating it against an allowlist, the attacker can execute arbitrary code in the caller's storage context. Since [[delegatecall executes code from another contract using the callers storage context]], this means the attacker's code runs with full access to the victim contract's storage, including token approvals and ownership state. The vulnerable pattern is a `forward()` or `proxy()` function that accepts a user-supplied `callee` address and passes it directly to `delegatecall(callee, msg.data)`. The [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation|Furucombo exploit]] ($14M, 2021) is the canonical demonstration. Since [[restricting delegatecall to pre-verified logic contracts prevents arbitrary code execution]], the defense requires maintaining a strict allowlist of valid delegation targets. (SWC-112) --- Relevant Notes: - [[delegatecall executes code from another contract using the callers storage context]] — the mechanism that makes this dangerous - [[furucombo exploit demonstrated unrestricted delegatecall enabling storage approval manipulation]] — the canonical exploit - [[restricting delegatecall to pre-verified logic contracts prevents arbitrary code execution]] — the defense pattern Topics: - [[vulnerability-patterns]]