Eighty-six Gnosis Safe wallets across Ethereum and Base were drained of roughly $3 million on Monday after attackers exploited a vulnerable third-party module named SquidRouterModule - a contract with no official connection to the Squid cross-chain protocol despite the name. The attack lasted approximately two hours. By the time it was over, the stolen assets had been converted into DAI stablecoin and consolidated into a single wallet. For operators using multi-signature wallet infrastructure to manage treasury, vendor payments, or on-chain business operations, the mechanics of this breach deserve close attention.
How Attackers Got Inside Without a Signature
The core flaw sat inside the module's executeSameChainActions() function. According to Blockaid, which reported on the incident, the function allowed unauthorized execution inside Safe accounts - meaning attackers could impersonate approved delegates and run transactions as if they were legitimate wallet users. No additional signature from the account holder was required, because the victims had already added the module as a trusted Safe extension.
That last point is where the real operational lesson lives. The moment a module is granted trusted status inside a Safe, it inherits the ability to act without prompting a fresh approval. The SquidRouterModule reportedly accepted a caller-supplied constant string as its proof of authorization - a flaw that was visible in the contract code itself. In practice, though, most operators who add modules to multi-sig wallets are focused on functionality, not on auditing the authorization logic line by line.
Attackers deployed Foundry-based exploit contracts to trigger delegated calls through the vulnerable module. Those calls executed token swaps directly from victim Safes. A fake token - reportedly labeled "u" - was created with a large supply, paired with real assets inside pre-funded Uniswap V3 liquidity pools controlled by the attacker, and used solely as the mechanism for draining funds. After the drain, attackers removed liquidity and completed swaps into stablecoins. The proceeds - approximately 3.07 million DAI according to on-chain data - were routed into a single consolidation address.
What Squid Actually Said, and Why the Name Confusion Matters
Squid, the decentralized cross-chain liquidity platform, responded quickly on X, stating clearly that the SquidRouterModule was not part of its official system. The team confirmed that its official router contract was not involved and remains unaffected. All Squid users and integrators, the team wrote, are unaffected and no action is needed.
Fair enough - and the clarification was necessary. The name similarity between the malicious module and Squid's legitimate infrastructure created real confusion in the hours following the attack. That confusion is itself a risk worth naming. In decentralized finance, contract names carry reputational weight. A module that borrows the name of a recognized protocol can gain user trust it hasn't earned. For any operator adding third-party modules to production wallets, name recognition is not a substitute for contract verification.
The Broader Pattern Behind This Specific Incident
This exploit sits within a documented trend. According to PeckShield data cited in Blockaid's reporting, approximately $328.6 million has been stolen across eight bridge-related exploits in 2025 alone. Aggregate figures from DeFiLlama place total crypto losses over time above $16.5 billion, with cross-chain bridge attacks accounting for roughly $3.22 billion of that total.
The pattern that connects many of these incidents is not exotic cryptography or novel attack vectors - it's delegation logic. Protocols that allow external modules, routers, or integrations to act on behalf of users without per-transaction authorization create a surface that attackers understand better than most deployers do. The more composable the system, the more entry points exist. That's not an argument against composability; it's an argument for treating module permissions the same way a compliance officer would treat access controls on a back-office system.
Operational Takeaways for Businesses Using Multi-Sig Infrastructure
For businesses - cannabis operators included - that use Gnosis Safe or comparable multi-sig wallets to manage operational funds, vendor settlements, or treasury assets, this incident carries a direct message. Adding a third-party module to a Safe is not a low-stakes configuration decision. It is an authorization grant. Here's the catch: once that grant is in place, it doesn't require your signature to act.
- Audit every module currently added to any production Safe wallet - verify the deployer, the contract address, and whether the code has been independently audited
- Never rely on a module's name as confirmation of its provenance; cross-reference against the official documentation of the protocol it claims to represent
- Treat module authorization reviews as a recurring operational task, not a one-time setup step
- Monitor wallet activity for unexpected token approvals, delegate assignments, or outbound swaps
Cannabis businesses operating in a heavily regulated, largely cash-adjacent environment have good reasons to use blockchain-based treasury tools - and equally good reasons to treat those tools with the same compliance discipline applied to seed-to-sale tracking or point-of-sale audit logs. The asset class is different. The operational risk mindset shouldn't be.
