Safe DELEGATECALL to Untrusted Address Exploits

introduction

CONTEXT-PRESERVING EXECUTION IN SAFE PROXIES

The Proxy DELEGATECALL Threat Model

Understanding why DELEGATECALL to an untrusted address is an existential threat to Safe's proxy architecture, and how flawed module or fallback handler logic creates a complete account takeover vector.

Safe smart accounts use the canonical proxy pattern where a lightweight proxy contract delegates all execution logic to a shared singleton contract via DELEGATECALL. This design means the proxy does not execute its own code; it borrows the singleton's logic while operating on its own storage. The critical security property is that DELEGATECALL preserves the caller's context—msg.sender, msg.value, and most importantly, the proxy's entire storage layout. If an attacker can force the proxy to DELEGATECALL into a malicious contract, that contract executes with full write access to the Safe's storage, enabling complete takeover: changing the owner set, draining assets, or altering the singleton reference to point to a permanently compromised implementation.

The attack surface for this threat model is concentrated in two privileged execution paths: the fallback handler and authorized modules. Both are invoked via DELEGATECALL from the Safe proxy. The fallback handler is designed to handle arbitrary function calls that the singleton does not recognize, making it a powerful extensibility mechanism. However, if a malicious fallback handler is socially engineered into approval—or if a legitimate handler contains a hidden vulnerability—the attacker gains the ability to execute arbitrary logic in the Safe's storage context without needing to pass the standard multisig threshold. Similarly, a flawed module that itself performs a DELEGATECALL to a user-supplied address can be weaponized to redirect execution into an attacker-controlled contract, bypassing the module's intended security checks.

Detecting unauthorized fallback handler changes is a critical operational control. The fallback handler address is stored at a known storage slot in the Safe proxy, and any change requires a standard multisig transaction. Integrators and risk teams should implement off-chain monitoring that alerts on any ChangedFallbackHandler event, and on-chain transaction guards that can block execution if the fallback handler address does not match an approved list. For modules, the risk is compounded by composability: a module that accepts an arbitrary address parameter for a DELEGATECALL is inherently dangerous unless it enforces strict allowlists. Security audits of Safe deployments must treat any code path that can influence the target of a DELEGATECALL as a critical vulnerability, and integrators should verify that all modules and handlers in use have been reviewed for this specific threat pattern.

DELEGATECALL TO UNTRUSTED ADDRESS

Exploit Class at a Glance

A structural overview of the vulnerability class where a Safe proxy is forced to DELEGATECALL into a malicious contract, granting the attacker full control over the Safe's storage and logic.

Area	What changes	Who is affected	Action
Execution Context	The Safe proxy executes logic in its own storage context via DELEGATECALL, meaning any code run can overwrite owners, thresholds, and nonces.	All Safe deployments using the canonical proxy pattern.	Audit all contracts reachable via DELEGATECALL from the Safe proxy.
Fallback Handler	A malicious or buggy fallback handler is set on the Safe, allowing arbitrary execution without a multisig vote.	Safes where the fallback handler address can be changed by a single owner or module.	Monitor for unauthorized fallback handler changes; verify handler code on-chain.
Module Logic	A flawed module or guard invoked via DELEGATECALL can manipulate the Safe's storage to bypass its own security checks.	Safes using custom or third-party modules and transaction guards.	Require a security review of all modules for storage collision and context confusion risks.
Signature Validation	An attacker crafts a payload that, when decoded by the wallet UI, appears benign but executes a malicious DELEGATECALL.	Signers who rely on wallet UI decoding without independent transaction simulation.	Implement independent transaction simulation and structured payload decoding.
MultiSend Path	A batched transaction via MultiSend includes a DELEGATECALL to an untrusted address, hiding the malicious step within a larger operation.	Safes using MultiSend for complex treasury or protocol operations.	Decode and simulate the full MultiSend batch before signing; verify each target address.
Module-Generated Signatures	A module that independently generates signatures fails to bind execution to a specific chain ID, enabling cross-chain replay of a malicious DELEGATECALL.	Safes using Allowance Modules, Zodiac Modifiers, or other signature-generating modules.	Verify that module-generated signatures include chainId and verifyingContract binding.
Guard Bypass	A transaction guard invoked via DELEGATECALL manipulates storage to bypass its own checkTransaction or checkAfterExecution hooks.	Safes relying on guards for security-critical policy enforcement.	Audit guard contracts for storage collision and reentrancy vulnerabilities within the execution lifecycle.
Indexer Data Poisoning	The Safe Transaction Service serves incorrect data, causing the front-end to display a fake owner set or nonce, tricking signers into approving a malicious DELEGATECALL.	Integrators and users who trust the Safe Transaction Service without independent on-chain verification.	Run an independent indexer or verify all transaction service data against on-chain state before signing.

technical-context

PROXY PATTERN VULNERABILITY CLASS

Root Cause: Unvalidated DELEGATECALL Targets

The fundamental mechanism enabling complete Safe takeover when a fallback handler or module is set to a malicious contract.

The Safe proxy architecture relies on DELEGATECALL to execute logic from a singleton implementation contract while preserving the proxy's own storage context. This pattern is standard for upgradeable smart accounts, but it creates a critical security boundary: any address that the proxy DELEGATECALLs into gains full, unrestricted write access to the Safe's storage. The fallback handler mechanism, designed to extend Safe functionality by forwarding unmatched function calls to a designated handler contract, becomes an existential threat vector when the handler address is not rigorously validated. If an attacker can set the fallback handler to a malicious contract—either through social engineering of signers or by exploiting a flaw in a module with handler-setting permissions—that malicious contract executes in the Safe's own storage context.

The exploit mechanics are brutally simple. Once a malicious fallback handler is set, any call to the Safe proxy that does not match a core function signature (execTransaction, getOwners, etc.) is forwarded via DELEGATECALL to the attacker-controlled contract. The attacker's contract can then directly overwrite the owner set in the Safe's storage, change the singleton implementation address, or drain assets by writing arbitrary calldata that the proxy will execute as if it were the canonical singleton. Because the execution context is the Safe proxy itself, msg.sender checks in downstream token contracts see the Safe's address, not the attacker's. This bypasses the entire multisig security model without ever calling execTransaction. The attack does not require a single valid signature; it requires only that the fallback handler slot be pointed at a malicious address.

Detection of unauthorized fallback handler changes is a critical operational control. On-chain monitoring for ChangedFallbackHandler events—comparing the new handler address against a known allowlist of canonical and audited handler deployments—is the primary defense for integrators and treasury operators. However, monitoring alone is insufficient. The deeper lesson is that any module or guard contract with the ability to call setFallbackHandler (or execTransaction with a delegatecall that modifies the handler slot) must be treated as a privileged component subject to the same security review rigor as the core singleton. For teams deploying custom modules, the security review must explicitly trace every possible path that could result in a storage write to the fallback handler slot, including paths reachable through reentrancy or delegatecall chains initiated by seemingly benign module functions.

DELEGATECALL EXPLOIT IMPACT SURFACE

Affected Systems and Actors

Safe Operators & Treasury Teams

Treasury managers and multisig operators are the primary targets. An attacker who forces a DELEGATECALL to a malicious contract can drain all assets, change the owner set, or lock the Safe permanently.

Immediate actions:

Audit the current fallback handler address against the canonical handler for your Safe version and chain.
Verify that no unauthorized setFallbackHandler transactions exist in the Safe's history.
For high-value Safes, implement a monitoring alert on any ChangedFallbackHandler event.
Ensure all signers use a wallet interface that decodes delegatecall targets before signing.

Chainscore Labs can review your Safe's handler configuration, audit the transaction history for unauthorized handler changes, and design a monitoring suite that alerts on fallback handler modifications before execution.

implementation-impact

DELEGATECALL EXPLOIT MITIGATION

Detection and Prevention Controls

Operational and technical controls to detect and prevent unauthorized fallback handler changes and malicious DELEGATECALL execution in Safe deployments.

Fallback Handler Monitoring

Implement continuous on-chain monitoring for changes to the fallback handler address via setFallbackHandler. Any unplanned modification should trigger an immediate incident response, as it is the primary vector for redirecting DELEGATECALL to a malicious contract. Integrators should index the ChangedFallbackHandler event and alert on deviations from a known allowlist of audited handler addresses.

Transaction Simulation and Decoding

Require independent transaction simulation before signing for all Safe transactions, especially those interacting with the fallback handler or executing multiSend payloads. Wallet interfaces must fully decode DELEGATECALL sub-transactions to display the exact storage modifications and external calls. Blind signing a transaction that invokes the fallback handler is functionally equivalent to granting full control of the Safe.

Guard-Based Execution Validation

Deploy a transaction guard that explicitly validates the target address in any DELEGATECALL execution path. The guard's checkTransaction hook should revert if the to address is not in a pre-approved registry of canonical Safe modules and handlers. This provides a defense-in-depth layer even if the fallback handler is maliciously changed, as the guard can block the unauthorized execution.

Fallback Handler Allowlisting

Maintain a strict on-chain allowlist of permitted fallback handler implementations. Any handler not present in this registry should be treated as malicious. For high-security deployments, consider using a custom Safe proxy that hardcodes the fallback handler address or restricts setFallbackHandler to a timelocked governance process, preventing single-transaction handler swaps.

Independent Indexer Verification

Do not rely solely on the Safe Transaction Service for transaction history and state display. Run an independent indexer that directly reads StorageAccessible events and fallback handler state from the chain. This prevents data poisoning attacks where a compromised transaction service hides a malicious handler change from signers reviewing the transaction queue.

Module and Handler Audit Scope

Ensure every security audit of a Safe deployment explicitly covers the fallback handler's execution context and any custom modules that use DELEGATECALL. Auditors must verify that handlers do not contain selfdestruct, unchecked external calls, or storage collisions that could be exploited via the proxy's context. Post-audit, lock the handler implementation to prevent upgrades that could introduce new vulnerabilities.

DELEGATECALL TO UNTRUSTED ADDRESS VULNERABILITY CLASS

Risk Matrix: Exploit Vectors and Mitigations

Systematic breakdown of attack vectors where a malicious contract is forced into the Safe's execution context via DELEGATECALL, the affected components, and the required mitigation or detection steps for each scenario.

Exploit Vector	Failure Mode	Affected Components	Severity	Mitigation and Detection
Malicious Fallback Handler	Attacker socially engineers signers into approving a transaction that changes the fallback handler to a malicious contract. The handler then executes arbitrary logic in the Safe's storage context via DELEGATECALL.	SafeManager, FallbackManager, multisig signers	Critical	Monitor FallbackManagerChanged events for unauthorized handler updates. Implement independent transaction simulation that decodes handler changes before signing. Review all handler addresses against a known-good registry.
Compromised Module DELEGATECALL	A legitimate module enabled by the Safe contains a vulnerability that allows an attacker to force the module to DELEGATECALL into an attacker-controlled address, inheriting the Safe's execution context.	SafeModuleManager, custom modules, Zodiac modules	Critical	Audit all enabled modules for DELEGATECALL to user-supplied addresses. Verify module upgrade paths and ownership. Disable modules that do not strictly validate their call targets. Use a module allowlist.
Guard Bypass via Storage Collision	A malicious contract called via DELEGATECALL manipulates storage slots that the transaction guard relies on for security checks, causing the guard to approve a transaction it would otherwise reject.	GuardManager, transaction guards, checkTransaction hook	High	Audit guard contracts for storage layout collisions with the Safe singleton. Guards must not rely on mutable storage that can be overwritten by the execution context. Use immutable variables or verify storage assumptions in guard logic.
multiSend Payload Injection	An attacker crafts a multiSend batch that includes a DELEGATECALL to a malicious contract disguised as a benign interaction. Signers approve the batch without decoding the full execution path.	MultiSend contract, Safe transaction builder, wallet interfaces	High	Implement recursive decoding of multiSend payloads in transaction simulation tools. Display the full execution tree to signers, not just the top-level operation. Flag any DELEGATECALL to non-whitelisted addresses.
Module-Generated Signature Replay	A module that independently generates signatures for execution uses DELEGATECALL without binding the signature to a specific chainId or Safe address, allowing cross-chain replay of module-initiated transactions.	Custom modules, EIP-712 implementation in modules	High	Verify that all module-generated signatures include chainId and the Safe's address in their domain separator. Audit module signature schemas for replay paths. Test module behavior across multiple chain deployments.
Fallback Handler Silent Approval	A malicious fallback handler implements a callback that silently approves transactions without requiring the standard multisig threshold, bypassing the normal signing flow entirely.	FallbackManager, execTransaction flow, multisig threshold logic	Critical	Verify that the fallback handler does not implement any transaction approval logic. Monitor for transactions executed without the required number of signatures. Review fallback handler code for any execTransaction or approveHash callbacks.
Transaction Simulation Spoofing	A wallet interface fails to decode a DELEGATECALL to a malicious contract, displaying a benign simulation to the signer while the actual execution transfers asset control to an attacker.	Wallet integrations, transaction decoding libraries, Safe UI	High	Use independent transaction simulation tools that fully decode nested DELEGATECALL paths. Verify simulation output against on-chain state changes. Implement human-readable decoding of all sub-calls in the execution trace.
Unverified Singleton Upgrade	An attacker deploys a malicious singleton at a known or predicted address and tricks governance or a relayer into upgrading the Safe's master copy to that address.	Proxy upgrade mechanism, Safe proxy, governance process	Critical	Verify singleton addresses against the canonical Safe deployments registry before any upgrade. Implement a timelock on master copy changes. Monitor for ProxyUpdated events pointing to unverified contracts.

DELEGATECALL TO UNTRUSTED ADDRESS EXPLOITS

Incident Response and Remediation Checklist

A structured checklist for security teams, Safe operators, and integrators responding to a suspected or confirmed exploit where a malicious fallback handler or module forced the Safe proxy to DELEGATECALL into an untrusted contract, compromising storage and logic.

What to check:

Identify the Safe proxy address and immediately check if a malicious transaction is pending in the queue or already executed.
Verify the current fallback handler address by calling getFallbackHandler() on the Safe proxy.
Check for any unauthorized module enablement via isModuleEnabled().

Why it matters: A compromised fallback handler or module can execute arbitrary logic in the Safe's storage context. The attacker may have already queued a follow-up transaction to drain assets. Time is critical.

Containment steps:

If a malicious transaction is pending, attempt to cancel it by executing a transaction with the same nonce to a benign destination (e.g., a self-transfer of 0 ETH).
If the attacker has already changed the owner set or threshold, standard cancellation may be impossible. Immediately coordinate with remaining signers to execute a setFallbackHandler(address(0)) and disableModule() transaction if still possible.
If the Safe is fully compromised, notify all integrated protocols (DeFi positions, vesting contracts) to pause or revoke approvals from the Safe address.
Engage Chainscore Labs for emergency triage and on-chain forensic analysis to determine the full extent of the compromise.

resource-links

SAFE INCIDENT REFERENCES

Canonical Resources and References

Use these sources to verify Safe contract behavior, canonical deployments, and the historical delegatecall backdoor pattern before assessing whether a Safe, module, guard, or fallback handler is exposed.

Safe Smart Account Contracts Repository

Review the Safe singleton, proxy, module manager, fallback manager, guard manager, and setup logic directly in the Safe smart account source. For delegatecall-risk analysis, focus on initialization paths, module execution paths, fallback handler storage slots, and any code path that executes external logic in the Safe proxy storage context. Operators should compare deployed bytecode against the tagged contract version they believe they are using before relying on UI labels or transaction service metadata.

EXPLORE

Safe Deployments Registry

Use the Safe deployments repository to validate canonical singleton, proxy factory, compatibility fallback handler, and related contract addresses across supported EVM chains. This is essential when investigating whether a Safe was created through a trusted factory path or through a forked, spoofed, or non-canonical deployment. Risk teams should reconcile the registry with on-chain bytecode, creation transactions, and chain-specific deployment records rather than assuming that an address is canonical because it appears in an interface.

EXPLORE

Safe Documentation

Safe documentation is the starting point for understanding supported account architecture, modules, guards, handlers, transaction execution, and integration assumptions. For this exploit class, teams should read the docs as an interface and behavior reference, then verify implementation details against the contracts repository. Pay particular attention to how modules and fallback handlers extend Safe behavior, because these extension points can become privileged control surfaces when installed during setup or modified through a signed Safe transaction.

EXPLORE

OpenZeppelin Backdooring Gnosis Safe Multisig Wallets Analysis

OpenZeppelin’s analysis is the canonical public write-up for the historical Safe setup backdoor class: a Safe can be initialized through a transaction that delegatecalls into attacker-controlled code and silently installs privileged modules. Security teams should use it to model deployment-time trust risk, not just post-deployment transaction risk. The practical takeaway is to distrust Safes created by untrusted deployers until the setup transaction, enabled modules, fallback handler, owners, threshold, and singleton bytecode are independently verified.

EXPLORE

On-Chain Verification Checklist

For any potentially affected Safe, inspect the proxy’s singleton target, owner set, threshold, module linked list, guard address, fallback handler address, and historical setup transaction. Decode calls that used delegatecall, MultiSend, module enablement, handler changes, or storage-writing helper contracts. Teams should also check whether a third party, hosted wallet flow, DAO tooling provider, or migration script created the Safe. If the Safe was initialized by an untrusted party, treat the account as compromised until module and handler state is proven clean on-chain.

Chainscore Labs Review Path

Chainscore Labs can help teams turn these references into an operational assessment: reconstruct Safe creation, diff deployed bytecode against canonical releases, decode initialization calldata, enumerate modules and fallback handlers, and identify delegatecall paths that could mutate Safe storage. This is most useful for treasuries, custody platforms, DAOs, wallets, and protocol teams that inherited Safes from third-party deployment flows or rely on custom modules, guards, relayers, or fallback handlers.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

DELEGATECALL EXPLOIT FAQ

Frequently Asked Questions

Common questions from security engineers, integrators, and risk teams investigating Safe Singleton DELEGATECALL vulnerabilities and fallback handler attack vectors.

DELEGATECALL executes the target contract's logic within the calling contract's storage context. If a Safe's fallback handler or module logic allows a DELEGATECALL to an attacker-controlled address, the attacker's code runs with full write access to the Safe's storage. This means the attacker can overwrite the owner set, change the singleton implementation address, or alter the nonce and threshold—effectively taking complete and irreversible control of the Safe. The proxy pattern that makes Safes upgradeable is the same mechanism that makes this attack class so severe: a single flawed DELEGATECALL can replace the entire security model of the account.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Safe Singleton DELEGATECALL to Untrusted Address Exploits

The Proxy DELEGATECALL Threat Model

Exploit Class at a Glance

Root Cause: Unvalidated DELEGATECALL Targets

Affected Systems and Actors

Safe Operators & Treasury Teams