Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Delegatecall injection occurs when an attacker can make a contract execute untrusted code with delegatecall. The delegated code runs against the caller's address, balance, and storage while preserving msg.sender and msg.value, as specified in the Solidity delegatecall documentation. It can therefore overwrite authority, corrupt accounting, or execute calls as the delegating contract.
The clearest defect is a public function that accepts both a target and calldata, then delegates to that target. Injection also arises when an attacker can change a stored implementation or library address, influence target selection through a registry, or seize an uninitialized proxy admin.
Not every proxy is vulnerable. A fallback that delegates to a stored implementation is the normal proxy mechanism. The security boundary is the provenance and mutability of that implementation, the authorization of upgrades, and compatibility between proxy and implementation storage.
A fixed trusted target can still be dangerous. Incompatible storage layouts, selector collisions, unsafe initialization, or delegated code that assumes a different caller context may corrupt state without target injection.
Enumerate every high-level and assembly delegatecall. Trace the target to its origin and list every function that can change it. Inspect initializers, proxy admin ownership, ownership of any shared implementation provider, UUPS upgrade authorization, governance execution, and emergency upgrade paths.
For standardized proxies, verify the deployed slots rather than inferring them from source. ERC-1967 defines implementation, shared-provider, and admin slots intended to avoid collisions with implementation state.
Test calls from unauthorized accounts, through multicalls and forwarders, before and after initialization, and after each supported upgrade. Upgrade tests should preserve all existing state and exercise rollback or recovery. Fuzz target and calldata inputs where either can be user-influenced. Assert that only approved authority can change implementation targets or shared-provider state.
Do not delegate to caller-supplied addresses. If a system is upgradeable, use a reviewed proxy architecture and make upgrade authorization explicit. The OpenZeppelin proxy API documents transparent, UUPS, shared-provider, clone, and ERC-1967 components; their authority and deployment requirements differ.
Validate new implementations for code presence and storage compatibility, but do not treat code length or a whitelist alone as proof of safety. Protect and initialize the implementation as required by the chosen pattern. Put consequential upgrades behind governance controls appropriate to their blast radius, and monitor the actual upgrade events and slots.
Making an implementation immutable removes upgrades but also removes the upgrade recovery path. It is a design tradeoff, not a universal fix.
Repository analysis can flag controllable targets, exposed setters, initializer paths, and likely layout hazards. It cannot prove that deployed slots match the repository, that an approved implementation is benign, or that upgrade keys are secure without deployment and custody evidence.
Is delegatecall itself unsafe?
No. It underpins libraries and proxies. The risk comes from untrusted code, incorrect context assumptions, unsafe upgrades, or incompatible storage.
Does only-admin upgrade authorization solve the issue?
It prevents arbitrary callers from upgrading only if the admin path is correctly initialized and controlled. The admin can still install malicious or incompatible code.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand missing and incorrect smart contract authorization checks, how to review privileged paths, and how to test role boundaries.
Review cross-chain message authentication, replay protection, finality, accounting, and operational trust boundaries.
Understand how atomic liquidity amplifies oracle, accounting, governance, and callback defects, with review and test guidance.
Understand governance capture, flash-loan voting, unsafe proposal execution, and the review and testing needed for on-chain governance systems.
Understand unsafe price-feed consumption, stale and low-liquidity data, oracle trust assumptions, and practical review and mitigation techniques.