The SquidRouterModule Exploit Shows Why Safe Wallet Security Is Now a Supply-Chain Problem

The latest DeFi exploit did not hit a flashy yield farm, a thinly audited memecoin contract, or a bridge holding hundreds of millions in pooled liquidity. It hit something more uncomfortable: smart accounts that many crypto users treat as the safer side of on-chain custody. A third-party module labeled “SquidRouterModule” was reportedly exploited across Ethereum and Base, draining roughly $3.2 million from 86 Gnosis Safe wallets in about two hours. The attacker then converted the stolen assets into DAI through Uniswap V3, consolidating the proceeds while the market was still trying to understand what had happened.

The incident is a reminder that “multisig” does not automatically mean “immune.” Safe wallets are powerful because they allow teams, DAOs, funds, and sophisticated users to add rules around asset movement. But that same flexibility can become a risk when external modules are granted execution power. The exploit appears to have targeted that extension layer, not the core Safe system and not Squid’s core router contract. That distinction matters. It means the failure was less about the base wallet architecture and more about the growing complexity of the smart-account ecosystem around it.

What Happened

Blockchain security firm Blockaid flagged an active exploit on May 25, reporting that 86 Gnosis Safe wallets had been drained across Ethereum and Base in roughly two hours. The losses were initially estimated at around $3 million and later reported by several outlets at approximately $3.2 million. The attacker converted the stolen tokens into DAI using Uniswap V3 pools, with reports indicating that the assets were consolidated into a single wallet holding a little over $3 million in DAI after the swaps.

Early reporting tied the exploit to a contract verified as “SquidRouterModule,” which created immediate confusion because Squid is also the name of a cross-chain routing protocol. Squid moved quickly to distance its core protocol from the incident, saying the exploit was unrelated to its core contracts and that Squid users and integrators were not affected. Safe Labs also characterized the issue as involving a third-party module rather than the Safe protocol itself.

The technical weakness appears to have been severe. Reports describe a flaw that allowed malicious transactions to execute without valid authorization, effectively letting the attacker impersonate approved execution paths and trigger arbitrary token movements from affected wallets. AMBCrypto, citing Blockaid, reported that the vulnerability involved the executeSameChainActions() function and enabled malicious transactions to impersonate authorized delegates.

Why the Word “Module” Matters

Safe wallets are often described as multisig wallets, but that description undersells what they have become. A Safe can be a treasury vault, a DAO operations account, a trading desk, an institutional custody layer, or an automated smart account. Modules are one of the mechanisms that make this flexibility possible. They allow additional contracts to perform certain actions on behalf of the Safe under predefined conditions.

That is useful. A team may want automated swaps, recurring payments, cross-chain execution, account recovery, spending limits, or integration with external protocols. Modules can make a Safe far more powerful than a basic wallet requiring manual signatures for every action.

But modules also expand the attack surface. A Safe may still require multiple human signatures for ordinary transactions, yet a module can have permissions that bypass the normal signing flow if it has been enabled and configured to execute specific operations. In a secure setup, that is intentional. In a vulnerable setup, it becomes a privileged backdoor.

The SquidRouterModule exploit appears to sit exactly in that danger zone. The attacker did not need to compromise every signer on every affected Safe. Instead, the reported flaw allowed execution through the module layer. That is a different class of risk from private-key theft. It is closer to software supply-chain risk: the core wallet can be sound, but an approved extension can still become the point of failure.

Why This Was Not Necessarily a “Safe Exploit”

The distinction between a Safe exploit and a third-party module exploit is not PR spin. It is central to understanding the event.

Safe’s core value proposition is that assets move according to defined permissions and signatures. If the core Safe contracts had been broken, the implications would be catastrophic across DeFi because Safe is widely used by protocols, funds, DAOs, and security-conscious users. Current reporting does not suggest that. The incident instead appears to have affected wallets that had interacted with or enabled the vulnerable third-party module.

That does not make the incident small. A $3.2 million drain from 86 wallets is serious. It also does not let the broader ecosystem off the hook. The reason Safe is so widely trusted is precisely because it has become infrastructure. When infrastructure becomes modular, users need better visibility into what they have installed, what permissions modules hold, and what latent execution rights remain active long after an integration is first used.

The lesson is not that Safe wallets are unsafe. The lesson is that a Safe wallet is only as secure as the full permission graph attached to it.

The Uniswap V3 Conversion Path

After draining the wallets, the attacker reportedly converted stolen assets into DAI through Uniswap V3. Several reports say the swaps were routed through attacker-controlled Uniswap V3 pools, which is a notable detail because it suggests the attacker may have structured liquidity to facilitate conversion and consolidation.

This is a familiar post-exploit pattern. Attackers often move quickly from heterogeneous stolen assets into a more liquid or more stable asset. DAI is useful for this purpose because it is widely supported across DeFi and easier to consolidate than a basket of volatile tokens. Speed matters. The first minutes after an exploit are when defenders, analytics firms, exchanges, bridge operators, and stablecoin issuers are still coordinating. By the time public alerts circulate, the attacker may already have swapped, bridged, split, or parked funds.

In this case, the two-hour window was long enough to drain dozens of wallets but short enough to create confusion about the exact root cause. That is why early security labeling matters. A contract name that includes “Squid” can create reputational blast radius for a protocol even if its core contracts were not impacted.

The Reputation Problem for Protocol Names

Squid’s public response highlights one of the messier realities of DeFi incident response. Contract labels, verified names, integrations, modules, and protocol branding do not always map cleanly to responsibility. A vulnerable contract can carry a name that points toward a project without the exploit necessarily affecting that project’s main protocol. In a fast-moving exploit, that nuance is often lost.

For users, the practical takeaway is simple: do not assume a brand-name integration is safe simply because the main protocol is known. For protocols, the takeaway is harsher: any external contract using your name, integrating your stack, or sitting adjacent to your ecosystem can become a reputational liability.

This is especially true for routing infrastructure. Routers, solvers, bridges, account modules, and intent systems often sit between users and execution. They are not always where users think their risk lives. The front-end may look familiar. The transaction may originate from a known wallet. The destination may involve a reputable DEX. But the dangerous permission may sit in a module approved weeks or months earlier.

The Bigger Issue: Smart Accounts Are Getting More Powerful

The exploit comes as the industry is moving toward account abstraction, intent-based execution, session keys, automated agents, and cross-chain smart accounts. This trend is broadly positive. Crypto wallets are still too hard to use, and smart accounts can make them more programmable, recoverable, and automated.

But every new convenience layer introduces a new trust boundary. Session keys can reduce signing fatigue, but they can also create delegated authority. Intents can improve execution, but they can expose users to solver risk. Modules can automate operations, but they can retain permissions users forget about. Cross-chain routing can improve liquidity access, but it can multiply the number of contracts involved in a single action.

The SquidRouterModule incident is therefore not just a one-off exploit. It is a preview of the security model DeFi now needs. The industry is no longer securing isolated contracts. It is securing interconnected permission systems.

What Users and Teams Should Learn

For retail users, the immediate lesson is to review token approvals and wallet permissions regularly. But for Safe users, that is not enough. They also need to understand enabled modules. A dangerous ERC-20 approval can let a spender move a token. A dangerous Safe module may be able to initiate broader wallet actions depending on its permissions.

For DAOs and teams, module management should become part of treasury operations. Any enabled module should have an owner, a reason for existing, a risk rating, and a review cycle. If a module is no longer needed, it should be removed. If a module is experimental, it should not be attached to a treasury holding meaningful assets. If automation is required, teams should consider spending limits, isolated operational Safes, and staged permissions rather than attaching broad execution rights to a primary vault.

The best treasury setups increasingly look like segmented systems. A cold Safe holds strategic assets. A smaller operational Safe handles routine activity. A hot execution account interacts with DeFi. Automation modules, if used, should sit as far away as possible from the deepest pool of funds.

Why Base and Ethereum Were Both Hit

The exploit affected wallets across Ethereum and Base, which is unsurprising given how users now operate. Many teams use the same tooling across multiple chains. Modules, routers, and account abstractions are deployed into several ecosystems to provide a unified experience. That cross-chain consistency is useful, but it also means a single vulnerable pattern can replicate across networks.

Base’s lower fees and growing DeFi activity make it an attractive execution environment. Ethereum remains the settlement and treasury layer for many protocols and teams. When a vulnerable module exists on both, the attacker can target both. This is one reason cross-chain security is so difficult: the blast radius is not limited to one chain if the same contract logic or permission assumptions appear elsewhere.

The Strength of Safe Still Depends on Operational Discipline

Safe remains one of the most important pieces of crypto custody infrastructure. It is widely used precisely because it gives users more control than an externally owned account. Multisig approvals, policy-based execution, and smart-account programmability are all valuable.

But Safe is not a magic shield. A team can still approve a malicious token. A signer can still be phished. A front-end can still be compromised. A module can still be dangerous. A governance process can still approve the wrong integration. The security benefit comes from discipline, not from the label “multisig” alone.

The SquidRouterModule exploit should push teams to treat modules as privileged software, not passive plugins. In traditional enterprise security, anything with administrative access is monitored, reviewed, logged, and periodically removed if unnecessary. Crypto treasuries need the same mindset.

The Weakness in DeFi’s Integration Culture

DeFi loves composability, but composability often creates unclear accountability. A wallet integrates a module. A module interacts with a router. A router touches a DEX. A DEX pool converts assets. A bridge may later move them. Each component may be secure in isolation, but the combined path can contain assumptions no single team fully owns.

That is the weak point attackers keep exploiting. They look for the seam between systems: the place where one contract assumes another contract validated a condition, where one module assumes a delegate is legitimate, where one front-end assumes a user understands a permission, or where one protocol name creates false confidence around another contract.

The reported arbitrary-execution flaw in SquidRouterModule is a textbook example of why integration security cannot stop at audits of core contracts. The glue code matters. The adapters matter. The modules matter. The permission checks matter most of all.

Verdict: A Small Exploit With Large Implications

At roughly $3.2 million, this exploit is not the largest DeFi hack of the year. But its importance is bigger than the dollar figure. It targeted the permission layer around smart accounts, which is exactly where more crypto activity is heading.

Squid says its core router contract and user funds were not affected. Safe’s core protocol does not appear to have been the root cause. Those are important clarifications. But the incident still exposes a deeper risk: users increasingly rely on complex wallet extensions that can hold powerful execution rights, and many do not fully understand what those extensions can do.

The future of crypto custody will not be only about private keys. It will be about permissions, modules, intents, solvers, session keys, and automated execution. That future can be safer and more usable than today’s wallet model, but only if the industry treats every extension as part of the security perimeter.

The SquidRouterModule exploit is a warning shot. Smart accounts are becoming the operating system of on-chain finance. Now DeFi has to secure the plugins.