The $3.2M SquidRouterModule Exploit: How a Public String Drained 86 Safe Wallets

TL;DR

On May 25, 2026, an attacker drained roughly $3.2 million from 86 Gnosis Safe wallets across Ethereum and Base in under two hours. The flaw was not in Safe's core contracts and not in Squid's cross-chain router. It lived in a third-party module called SquidRouterModule, a contract verified on Basescan under that name but, according to Squid, never built, deployed, or operated by Squid. The module's authorization check accepted a fixed constant string as proof of caller legitimacy, and that string was sitting in plain sight in the verified source code. Anyone who copied it could push arbitrary calls through every Safe that had enabled the module, with no owner signatures required. Funds were swapped to DAI through attacker-controlled Uniswap V3 pools and consolidated into a single wallet holding about 3.07 million DAI.

What Is a Gnosis Safe Module, and Why Is It a Skeleton Key?

Most coverage of this incident led with a branding fight: Squid distancing itself from a contract that carried its name. That part is real, and we will get to it. But the security story is about Gnosis Safe modules, and it is one every team running a Safe should understand cold.

A Safe (formerly Gnosis Safe) is a smart contract wallet. Normally, moving funds requires collecting the threshold of owner signatures, say 2-of-3, and submitting them to execTransaction. That signature check is the entire security model.

Modules bypass it. When a Safe enables a module, that module can call execTransactionFromModule and execute transactions directly, with zero owner signatures. The Safe trusts the module's own internal logic to decide what is allowed. This exists for good reasons: recurring payments, automated DCA, spending limits, session keys, and cross-chain routing all need to act without a human signing every transaction.

The tradeoff is brutal. An enabled module is a skeleton key to the wallet. Its access is only as strong as its weakest authorization check. If that check is broken, the module is not a feature anymore. It is a backdoor that every owner voluntarily installed.

The SquidRouterModule had a broken check.

How Did the SquidRouterModule Exploit Work?

According to Blockaid's analysis, the exploit originated in the module's executeSameChainActions() function, not in Safe's core infrastructure. Two design failures stacked on top of each other.

Failure one: a public string used as a secret. The function authenticated callers by comparing a caller-supplied string against a hardcoded expected value to "construct message authenticity," as one technical writeup described it. The problem: that expected value was hardcoded in the contract's source, which is verified and publicly readable on Basescan. Using a publicly visible constant as an authentication credential is a textbook instance of CWE-798: Use of Hard-coded Credentials. The secret was never secret. The attacker read it off the explorer and replayed it.

Failure two: unrestricted call execution. Once the string passed, the module imposed no constraints on what could be executed. It "allowed all calls without selective calldata to go through," handing the caller the ability to drive any transaction from inside the victim's Safe. There was no allowlist of target contracts, no function selector filtering, no value caps. This is CWE-862: Missing Authorization on the action itself: passing the identity gate granted total control.

Combine the two and the attack is trivial. Prove "authenticity" with a string anyone can read, then ask the module to execute anything. The Safe, seeing an instruction from a module it trusts, complies without asking for a single owner signature.

Concretely, the two failures meet in one execution path. Blockaid reported the attacker used Foundry-based exploit contracts that abused the module's DelegateBundler execution path. Supplying the known string was what made that path treat the caller as an authorized delegate connected to a victim wallet. With the delegate check satisfied and no calldata restrictions, the attacker triggered swaps directly from the affected Safes without the normal multisignature approvals.

How Did the $3.2M Drain Unfold?

Here is the full chain.

An example drain transaction shared by Blockaid landed at 06:25:23 UTC on May 25, 2026. All 86 wallets were emptied within roughly two hours.

One detail about the Uniswap V3 step. Routing the stolen tokens through pools the attacker controls converts a mix of freezable assets (Circle can blacklist USDC) into a single attacker-held asset. It is laundering disguised as ordinary DEX activity.

Was Squid Router Itself Responsible?

The contract was verified on Basescan as SquidRouterModule, and that name damaged Squid's reputation before the technical details surfaced. Squid's response was blunt: a third-party module was exploited, not Squid's router contract, and the contract "shares its name but not its code." Squid stated the module was not built, deployed, or operated by Squid, and that its own core router contracts, user funds, approvals, and integrated services were untouched. Squid users needed to take no action.

That claim is consistent with the on-chain evidence. The exploited logic lived entirely in the module, and Squid's actual router is a separate, unrelated contract. As of this writing, who deployed the malicious module remains unknown, the point The Block led with.

Safe Labs distanced itself too. CEO Rahul Rumalla said the affected accounts "do not seem to be operated on official Safe Wallet product" and that it was unclear "how and where they were created and managed." Notably, Safe's built-in Safe Shield, which uses Blockaid's risk detection, had already flagged the module as malicious before the drain.

Three parties, three disclaimers, all largely accurate. And yet 86 wallets still lost $3.2 million. Accurate disclaimers do not refund anyone.

Who Is at Fault When a Trusted Module Fails?

The naming was misleading, but a Safe does not enable a module by accident. Each of the 86 victims signed a transaction that granted this contract permission to move their funds without further approval. The trust was explicit and on-chain.

This is the uncomfortable part of the module model. The security boundary of your Safe is not your signing threshold. It is the union of your threshold and the internal logic of every module you have ever enabled. You can run a flawless 3-of-5 multisig and still lose everything to a 1-of-1 string check buried in a module you approved months ago and forgot about.

Module risk is also persistent. Unlike a single malicious transaction, an enabled module sits in the Safe's configuration indefinitely. It keeps that signature-free access until someone explicitly disables it. Most teams never audit their enabled-module list after setup. The access stays live and unwatched. This is the same pattern that produced the Kelp DAO $292M LayerZero DVN exploit: one trusted config sitting unreviewed until an attacker noticed.

What Can DeFi Teams Learn From This Exploit?

1. Treat enabling a module as the highest-risk action a Safe can take. It is strictly more dangerous than a single transfer, because it grants standing, signature-free authority. A module should clear the same bar as a contract upgrade: independent audit, source review, and named accountability for who deployed it.

2. A constant in verified source code is never a credential. Any authorization scheme that depends on a value an attacker can read off a block explorer is already broken. Authentication must rely on cryptographic signatures or msg.sender checks against known addresses, not on shared strings. This is a known and avoidable failure class (CWE-798).

3. Modules must restrict what they execute, not just who calls them. Even a correct caller check is not enough if the module then permits arbitrary calldata to arbitrary targets. Modules should enforce target allowlists, function-selector filters, and value caps. Identity authorization without action authorization (CWE-862) is half a security model.

4. A name is not a provenance check. A contract verified as SquidRouterModule is not Squid's, any more than a token named USDC is Circle's. Verify the deployer and the code, never the label. The entire incident hinges on users trusting a name.

5. Audit your installed modules on a schedule. Enabled modules are persistent attack surface. Teams should maintain an inventory of every module on every Safe they control, review it periodically, and disable anything unused or unaudited. The 86 victims had a malicious module installed and, apparently, nobody checking the lock.

For deeper context on how DeFi attacks compound when monitoring lapses, see the Drift Protocol $270M exploit breakdown and the Aave $27M oracle liquidation incident — both turn on the same root failure: trusted infrastructure that nobody was watching.

What Is the Current Status of the Stolen Funds?

As of May 26, 2026:

• The malicious SquidRouterModule is publicly identified, and Safe Shield / Blockaid had flagged it as malicious.
• Stolen funds were consolidated into 0x9bdc730183821b6bb2b51be30b77c964fa645b91 as roughly 3.07 million DAI.
• The deployer of the module remains unidentified.
• Squid maintains its core router and users were unaffected; Safe Labs says the affected accounts were not on its official product.
• No recovery of funds has been reported.

FAQ

Who deployed the SquidRouterModule?

Unknown. The contract was verified on Basescan under the name SquidRouterModule, but Squid has stated it did not build, deploy, or operate the module. As of May 26, 2026, the deployer's identity has not been publicly identified.

Is Squid Router itself safe to use?

According to Squid, yes. The exploited code lived entirely in a third-party module that only shared the Squid name. Squid's core router contracts, user funds, approvals, and integrated services were not affected, and Squid users were not required to take any action.

How do I check if my Safe has the SquidRouterModule enabled?

Inspect your Safe's enabled-modules list. In the official Safe Wallet UI, this is under Settings → Modules. On-chain, call getModulesPaginated() on your Safe contract. If SquidRouterModule appears, disable it immediately via an owner-signed transaction. Safe Shield (Blockaid) had flagged the contract as malicious before the drain.

Were any of the stolen funds recovered?

No recovery has been reported. The attacker consolidated proceeds into 0x9bdc730183821b6bb2b51be30b77c964fa645b91 as roughly 3.07 million DAI. Routing through attacker-controlled Uniswap V3 pools converted freezable tokens into a single asset under attacker control, complicating recovery.

You Can't Sign Off on a Backdoor You're Not Watching

The SquidRouterModule never needed a sophisticated exploit. The credential was published. The targets were enumerable on-chain. The only thing standing between the attacker and 86 wallets was a string anyone could read. An audit of the module would have caught the broken check in minutes, but the victims did not deploy it. They only enabled it, and enabling it was enough.

That is the monitoring gap. The dangerous event here was not the drain. It was the moment each Safe enabled an unaudited third-party module with signature-free execution rights, weeks or months before a single dollar moved.

Tripwire is built for this: new module enablement on your Safes, unrecognized contracts gaining execution rights, anomalous outflows, and known-malicious addresses flagged in real time. When a module you never vetted gets enabled, or a flagged contract touches your wallet, your team gets an alert in seconds through Slack, Telegram, or email. Pre-configured circuit breakers can act before the two-hour drain window opens.

Audits tell you a contract is safe. Tripwire tells you what just got permission to move your money.

If you operate Safes holding user or treasury funds, talk to us.

Sources

1. The Block — "We don't know who deployed this": Squid distances itself from $3.2 million third-party module exploit Retrieved: 2026-05-26
2. Cointelegraph — Third-Party Module Drains $3M From Safe Wallets Retrieved: 2026-05-26
3. crypto.news — Blockaid flags $3M SquidRouterModule exploit across 86 Safes Retrieved: 2026-05-26
4. crypto.news — Squid rushes to separate brand from $3 million Gnosis Safe module exploit Retrieved: 2026-05-26
5. Capitaxer — Here's how attackers drained $3.2M from Safe wallets on Ethereum and Base Retrieved: 2026-05-26
6. NullTX — $3 Million Drained In Two Hours: SquidRouterModule Exploit Retrieved: 2026-05-26
7. Coinpedia — $3M Drained from 86 Gnosis Safes in SquidRouterModule Exploit Retrieved: 2026-05-26
8. MITRE — CWE-798: Use of Hard-coded Credentials Retrieved: 2026-05-26
9. MITRE — CWE-862: Missing Authorization Retrieved: 2026-05-26