Skip to main content
• 7 min read

SquidRouterModule Exploit: $3.2M Drained
from 86 Safe Wallets via Third-Party Module Flaw

A third-party Safe module verified as SquidRouterModule was exploited across Ethereum and Base, draining 86 Safe accounts for roughly $3.0M-$3.2M after flawed delegate validation let attackers execute unauthorized swaps and consolidate about 3.07M DAI.

AUTOSEC.DEVAUTOSEC.DEV
SquidRouterModule Exploit: $3.2M Drained from 86 Safe Wallets via Third-Party Module Flaw
  • Incident Date: May 25, 2026
  • Target: Third-party Safe / Gnosis Safe module identified as SquidRouterModule on Ethereum and Base
  • Target Overview: Public reporting identified the affected component as an externally deployed Safe module, not Safe's core smart-account contracts and not Squid's production router. The module had been granted execution permissions by affected Safe accounts, allowing it to act inside those wallets when its own authorization checks passed.
  • Affected Accounts: At least 86 Safe / Gnosis Safe accounts across Ethereum and Base
  • Known Addresses: Reported exploiter address 0x9bdc730183821b6bb2b51be30b77c964fa645b91; reported consolidation wallet 0xA447F71782135AB96a71374271a749Ff7AA54859
  • Total Loss: Approximately $3.0 million to $3.2 million, with public tracing showing about 3.07M DAI consolidated after swaps
  • Recovery Status: No public recovery, reimbursement plan, or final technical post-mortem had been identified in the reviewed sources.
  • Attack Vector: Third-Party Safe Module Vulnerability / Delegate Impersonation / Caller-Supplied Authorization Proof / Arbitrary Calldata Execution / Attacker-Controlled Uniswap V3 Liquidity

Incident Review & Technical Details​

1. Attack Path​

  1. A Third-Party Module Held Wallet-Level Execution Rights: The affected Safe accounts had enabled a module identified as SquidRouterModule. Safe modules can execute actions on behalf of a Safe once trusted, so a module bug can bypass the normal owner-approval path even when the Safe contracts themselves behave correctly.
  2. Authorization Was Reduced to Weak Module-Side Validation: Public technical summaries said the module accepted a caller-provided constant string or otherwise insufficient identity proof as evidence that a message was authorized. That made the module's own verification checks the weak point.
  3. Attack Contracts Impersonated Delegates: Reporting from Blockaid-derived coverage said the attacker deployed Foundry-based exploit contracts and abused the module's DelegateBundler path to impersonate authorized delegates for victim Safes.
  4. executeSameChainActions() Became the Entry Point: Early findings tied the exploit to the module's executeSameChainActions() flow. Once verification was bypassed, the attacker could cause the module to execute arbitrary swap calldata from the affected Safes without fresh owner signatures.
  5. Victim Assets Were Routed Through Attacker-Controlled Pools: Stolen assets including USDC, USDT, ENA, and other tokens were swapped through attacker-controlled Uniswap V3 liquidity, including routes involving an attacker-created low-value token reported as u.
  6. Liquidity Was Removed and Proceeds Were Consolidated: After forcing swaps through the seeded pools, the attacker removed liquidity and consolidated proceeds into DAI. Public tracing placed the consolidated amount around 3.07M DAI.
  7. The Drain Completed Quickly: Blockaid and follow-on reporting described 86 Safes drained in roughly two hours across Ethereum and Base, with the exploiter address reportedly funded by 2.1 ETH from Tornado Cash before the attack.

2. Impact Scope​

  • Direct Economic Impact: Public loss estimates ranged from roughly $3.0 million to $3.2 million.
  • Affected Networks: Ethereum and Base were the reported execution environments.
  • Affected Wallets: The exposed accounts were Safe / Gnosis Safe accounts that had trusted the vulnerable third-party module.
  • Affected Assets: Reports referenced assets such as USDC, USDT, ENA, COW, and other tokens before consolidation into DAI.
  • Unaffected Components: Safe Labs and Squid statements, as reported by media, said the incident was not a compromise of Safe core infrastructure or Squid's core router contracts.
  • Attribution Risk: The vulnerable contract's name created confusion because it used the SquidRouterModule label. Squid said the module was not built, deployed, or operated by the Squid team and that core Squid users and integrators were unaffected.
  • User-Interface and Integration Risk: Safe Labs' CEO reportedly said the affected accounts did not appear to be operated through the official Safe Wallet product and were likely created or managed through external integrations. He also said Safe Shield had flagged the module as malicious through Blockaid-powered detection rules.

3. Root Cause Assessment​

This incident is best understood as a module authorization failure inside the smart-account trust boundary. Safe modules are powerful by design: once enabled, they can execute wallet actions without collecting a fresh owner signature for every transaction. That is useful for automation, but dangerous when the module's authentication model is weaker than the Safe's owner threshold.

Key risk patterns to examine:

  • Module Permissions Were Equivalent to Wallet Control: A trusted module can become a second transaction engine for a Safe. If its checks fail, the wallet's assets can be spent even though Safe core approval logic remains intact.
  • Caller-Controlled Authorization Material Was Trusted: A caller-supplied constant string or weak proof is not an authority boundary. Authorization must be bound to a trusted signer, expected delegate, nonce, deadline, chain ID, target Safe, route, assets, amounts, and verifying module.
  • Delegate Identity Was Not Strongly Bound: The attacker reportedly impersonated authorized delegates through the DelegateBundler path. Delegate validation should never depend on data that an untrusted caller can freely choose or replay.
  • Arbitrary Calldata Expanded Blast Radius: Once the attacker could pass module verification, the ability to execute arbitrary swap calldata made the module a direct asset-drain primitive.
  • Attacker-Controlled Liquidity Hid the Economic Extraction Path: Routing victim assets through attacker-seeded Uniswap V3 pools into a worthless token let the attacker translate wallet balances into removable liquidity and then DAI.
  • External Integrations Can Bypass Wallet UX Warnings: If users create or manage Safes through third-party tooling, they may not receive the same warnings, module provenance checks, or risk prompts exposed in the official wallet interface.

The core invariant should have been strict: no enabled module may spend Safe assets unless the requested action is authorized by a trusted, non-caller-controlled identity and cryptographically bound to the exact Safe, route, token set, calldata, nonce, deadline, and chain.

4. Mitigation and Response​

Recommended actions for Safe users, integrators, module developers, and wallet platforms:

  • Immediately review enabled Safe modules and disable any unknown, unverified, or no-longer-needed modules.
  • Treat module enablement as equivalent to granting privileged wallet execution, not as a low-risk integration setting.
  • Require multi-owner approval, delay windows, and clear risk prompts before enabling modules or guards in production treasury Safes.
  • Bind module authorization to EIP-712 typed data that includes the Safe address, chain ID, module address, target contracts, token addresses, amounts, calldata hash, delegate identity, nonce, and expiry.
  • Reject caller-provided constants, caller-selected signers, reusable proof strings, and unbound delegate identifiers as authorization evidence.
  • Deny arbitrary calldata execution unless the module has a narrow, audited allowlist of selectors, routers, token pairs, slippage bounds, and recipients.
  • Add replay protection and per-Safe nonces for every delegated execution path.
  • Monitor EnabledModule, module execution, guard changes, suspicious Uniswap V3 pool creation, abnormal swaps into thin pools, and large same-block liquidity removals.
  • Integrators should surface Safe Shield-style warnings and independent module reputation checks when users create Safes through external products.
  • Module developers should publish deployer provenance, verified source, audit scope, privileged roles, supported router addresses, and emergency disable guidance.
  • Convert this incident into regression tests for malicious delegates, caller-supplied proof strings, forged route data, arbitrary swap calldata, fake-token pools, and cross-chain deployments.
  • Publish a final post-mortem with the vulnerable module address, source code diff, transaction set, affected Safe list or scoping method, recovery status, and concrete user remediation instructions.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The SquidRouterModule incident shows why smart-account security must include every enabled module, guard, signer workflow, and integration UI around the wallet. A Safe can remain technically correct while a trusted module becomes the real asset-control layer.

  1. Smart-Account Module Review: AUTOSEC.DEV reviews Safe modules, guards, delegated execution flows, owner thresholds, module enablement paths, provenance, and emergency disable controls.
  2. Authorization & Delegate Validation Audit: We examine EIP-712 payload binding, signer and delegate registries, nonce handling, replay controls, calldata restrictions, router allowlists, and user-controlled trust-root mistakes.
  3. Wallet Integration Risk Assessment: We test third-party Safe creation flows, module warning coverage, permission prompts, transaction simulation, and Safe Shield-style detection handoff across external interfaces.
  4. Incident Response (IR): AUTOSEC.DEV supports exploit reconstruction, affected-wallet scoping, fund-flow tracing, emergency module disablement, user remediation guidance, and post-incident hardening.

Service Content​

Reference​