A new DeFi security incident has put smart wallet permissions back under scrutiny after attackers drained about $3.2 million from Safe-linked wallets across Ethereum and Base. The exploit, identified by blockchain security firm Blockaid, reportedly affected at least 86 Gnosis Safe wallets and centered on a third-party module known as SquidRouterModule.
The incident did not appear to compromise Safe’s core infrastructure. Instead, early analysis points to a flaw in a third-party wallet module that had been granted delegated execution permissions. That distinction matters for the wider crypto market because it highlights one of the most important security trade-offs in decentralized finance: smart accounts can offer flexibility, automation, and better user experience, but delegated permissions can become dangerous if a trusted module is poorly designed or improperly verified.
The stolen assets were reportedly converted into Dai through attacker-controlled Uniswap V3 pools, with proceeds later consolidated into a wallet holding roughly 3.07 million DAI. On-chain investigators also linked the exploiter wallet to funding through Tornado Cash, adding another layer of complexity to the tracing process.
For crypto investors and DeFi users, the attack is a reminder that wallet security is no longer only about seed phrases, private keys, or exchange custody. As smart contract wallets become more common, the permissions attached to external modules, routers, guards, and integrations are becoming equally important.
Why the Safe Wallet Exploit Matters for DeFi
The exploit is significant because it appears to involve delegated execution rather than a simple private-key compromise. In traditional crypto wallet attacks, users often lose funds because a private key is stolen, a malicious signature is approved, or a phishing transaction grants token access to an attacker. This case is different.
According to early findings from Blockaid, the attack exploited a flaw inside the executeSameChainActions() function of the third-party module. The attacker allegedly used Foundry-based exploit contracts to abuse the module’s DelegateBundler execution path and impersonate authorized delegates connected to victim wallets.
Once the verification checks were bypassed, the attacker could trigger swaps from the affected Safe wallets without the standard multisignature approvals normally expected in Safe transactions. This is the key market concern. If a module has already been granted broad permission, a vulnerability in that module can allow attackers to move faster than normal user approval flows would permit.
For DeFi, this raises a broader risk question. The sector increasingly depends on composability, where wallets, protocols, routers, liquidity pools, and automation tools interact with each other. That creates efficiency, but it also creates new attack surfaces. A weakness in one layer can affect users who assumed their funds were protected by another layer.
Delegated Permissions Become the Weak Point
Safe wallets are widely used because they allow more advanced account structures than standard externally owned accounts. Users can configure multisignature approvals, add modules, install guards, and interact with DeFi protocols in more sophisticated ways. For DAOs, funds, teams, and advanced users, this flexibility is one of the main advantages of smart contract wallets.
However, modules are powerful. Unlike standard Safe transactions, which require approval from wallet owners, modules can execute actions directly once they have been granted trusted permissions. That is useful for automation, routing, batch transactions, and cross-chain workflows. It is also risky if a module’s identity validation is weak.
In this incident, the vulnerability appeared to allow malicious requests to appear as if they came from authorized delegates. Technical analysis shared by SlowMist founder Cos suggested that sampled victim wallets were mostly single-signature Safes owned by different users, and that the weakness was linked to vulnerable wallet modules rather than compromised private keys.
That detail is important. It suggests the affected users may not have lost funds because they exposed their keys. Instead, they may have been exposed through permissions granted to an external module. For users, this makes risk harder to detect because the dangerous element may not be visible in day-to-day wallet activity.
How the Attack Converted Assets Into Dai
After gaining unauthorized execution access, the attacker reportedly swapped legitimate assets from the affected wallets into a worthless attacker-created token identified as “u.” Liquidity was then removed, and proceeds were converted into Dai through Uniswap V3 pools controlled by the attacker.
This route reflects a common pattern in DeFi exploits. Attackers often move quickly to convert stolen assets into more liquid, stable, or easier-to-consolidate tokens. Dai is frequently used in DeFi because it has deep liquidity, broad protocol support, and can be moved across different environments with less volatility than assets such as ETH or smaller tokens.
The use of attacker-controlled liquidity pools also shows how DeFi infrastructure can be manipulated during an exploit. Liquidity pools are designed to enable open market trading, but when an attacker controls both the malicious token and part of the liquidity path, they can create swap routes that extract value from victim wallets while making the transaction appear as a series of smart contract interactions.
The reported timeline is also notable. The exploit drained dozens of accounts within roughly two hours. That speed matters because once a module-level flaw is actively exploited, users may have limited time to revoke permissions, disable modules, or move assets before attackers complete the drain.
Safe Labs Says Official Safe Wallet Product Was Not Affected
Safe Labs CEO Rahul Rumalla later said the compromised accounts did not appear to be operated through the official Safe Wallet product. He indicated that investigators still did not know where the affected wallets were originally created and managed, but suggested they were likely deployed through external integrations.
This distinction is relevant for market confidence. If the exploit had involved Safe’s core contracts or official product infrastructure, the implications would have been much broader. Safe is a major part of DeFi’s institutional and treasury management stack, and a core-level vulnerability could have triggered much wider concern.
Instead, the current analysis points toward a third-party integration risk. That does not make the incident less serious for affected users, but it changes the interpretation. The weakness appears to sit in the permissioned module ecosystem around smart wallets rather than in Safe itself.
Rumalla also said Safe Shield, a built-in warning system powered by Blockaid, had already identified the module as malicious before the incident. According to the statement, the system is designed to alert users when unverified modules or guards request dangerous permissions. This adds another lesson for the market: security warnings only help when users and integrators understand them, trust them, and act before permissions are abused.
Squid Denies Link to Official Router Infrastructure
Squid also denied that its official routing infrastructure or core contracts had been breached. The team said the exploited contract merely shared the SquidRouterModule name and had no connection to Squid’s production router architecture.
This matters because naming confusion can quickly create reputational risk in crypto. When a malicious or vulnerable contract uses a name similar to a known protocol, users may assume the official protocol was compromised even if the exploit involved an unrelated third-party module.
Squid said its users and integrators remained unaffected and described the event as a third-party smart-wallet module exploit unrelated to its official services. For traders and DeFi participants, this distinction is important but also points to a larger ecosystem problem: users often struggle to verify whether a module, contract, or integration is truly official.
That verification gap can become a security issue. In a permission-based environment, contract identity matters as much as contract code. If users approve the wrong module, or if an integration deploys wallets with unsafe module permissions, losses can occur even when major protocols remain technically uncompromised.
Market Impact: Security Risk Remains a DeFi Valuation Factor
The direct financial damage of about $3.2 million is not large enough to destabilize the broader crypto market. However, the incident may still influence DeFi sentiment because it follows a growing list of security failures in 2026. Recent exploits have increasingly involved permissions, admin controls, delegated authority, or operational weaknesses rather than simple code bugs in isolated contracts.
That trend matters for investors. DeFi valuation depends not only on total value locked, trading volume, fees, or token incentives. It also depends on trust in infrastructure. If users believe smart accounts, modules, bridges, or protocol integrations can introduce hidden risk, they may demand higher security standards before committing capital.
For Ethereum and Base, the exploit does not indicate a blockchain-level failure. The networks continued operating normally, and the issue appears to be application-layer risk. Still, application-layer exploits can affect user confidence, especially on networks where DeFi activity depends heavily on integrated tooling and automated wallet interactions.
Security incidents can also affect protocol tokens indirectly. If a project is perceived as linked to an exploit, even through naming confusion or third-party integrations, market participants may react cautiously until the scope is clarified. In this case, Safe and Squid both moved to separate their official infrastructure from the affected module, which may help contain reputational spillover.
What DeFi Users Should Watch Next
The most important issue now is whether investigators identify additional affected wallets, related exploit contracts, or copycat risks. Once an attack method becomes public, other malicious actors may attempt to scan for wallets using similar vulnerable modules.
Users of smart contract wallets should pay attention to module permissions, especially if their wallets were deployed through third-party integrations rather than official interfaces. The key risk is not only whether a wallet is a Safe, but which modules, guards, routers, and automation permissions have been installed.
DeFi teams may also need to review how they handle delegated execution. Any module that can bypass normal approval flows needs strict verification, clear user warnings, limited permissions, and emergency removal options. Broad execution rights may improve convenience, but they can also create concentrated failure points.
For traders, the incident is another reminder that DeFi risk is not fully captured by token prices or protocol yields. Smart contract exposure, wallet configuration, liquidity routing, and operational security all matter. A yield opportunity can become irrelevant if the underlying permission structure allows funds to be moved without expected approvals.
The $3.2 million Safe wallet module exploit highlights a growing security challenge in crypto: the shift from simple wallet custody risk to complex permission-layer risk. The attack appears to have targeted a vulnerable third-party module rather than Safe’s core infrastructure, but the outcome was still severe for affected users.
The incident shows how powerful smart wallet modules can become when granted delegated execution permissions. If identity checks fail, attackers may be able to trigger transactions that users never manually approved. That is a serious concern as DeFi continues moving toward smarter, more automated account systems.
The Safe wallet exploit does not appear to be a core Safe breach, but it exposes a critical DeFi risk: third-party modules with broad permissions can become attack paths if verification fails. Investors and users should watch for stronger module audits, clearer wallet warnings, and tighter controls around delegated execution before assuming smart accounts are automatically safer than traditional wallets.
