Third-Party Safe Module Exploit Drains $3.2M from Squid Wallets

86 wallets. $3.2 million. One module that nobody was watching closely enough. On May 25, 2026, a third-party component called SquidRouterModule, bolted onto Safe smart account infrastructure, was exploited across Base and Ethereum. The core Safe contracts were untouched. Squid's own protocol was untouched. The hole was in the connective tissue between them. According to reporting by Coinpedia and CoinLaw, blockchain security firms corroborated Squid's attribution within hours of the incident.

The thesis here is simple. The industry has spent years auditing core contracts. It has not spent nearly enough time auditing what gets attached to them. This exploit is not a Squid story. It is a modular security story. And it has direct consequences for every treasury manager, tokenization platform builder, and institutional operator running on-chain custody through a composable wallet stack.

What Happened

Squid is a cross-chain routing protocol. According to Morningstar, it raised $6 million in strategic funding just three days before this incident, with Ripple participating in the round. The platform supports over 20,000 tokens across more than 100 blockchain networks and has facilitated over $6 billion in volume. It is not a small experiment. It is active infrastructure.

On May 25, 2026, a third-party Gnosis Safe module integrated with Squid's wallet infrastructure was exploited. According to Coinpedia, the attacker drained approximately $3.2 million from 86 Gnosis Safe wallets operating on Base and Ethereum. The specific module identified in reporting is SquidRouterModule.

Squid moved quickly to clarify that the exploit did not originate in its core protocol. According to Bitcoin Foundation News, Squid publicly stated that the exploit was unrelated to its core protocol and contracts, and that all Squid users and integrators were unaffected. Crypto.news reported the same language verbatim from Squid's official statement: "This incident is unrelated to Squid's core protocol and contracts. All Squid users and integrators are unaffected and no action is needed."

That statement is technically accurate as far as the core protocol is concerned. As a complete security lesson for operators, however, it leaves important questions unanswered. The module that failed was a third-party component that Squid-connected wallets had approved and integrated. The wallets that lost funds were real wallets holding real value. The people who lost money were not comforted by the fact that the core protocol was fine.

As of the time of writing, Safe Labs had not issued a formal post-mortem confirming or disputing the attack vector. For institutional operators relying on Safe infrastructure, that gap in public information is relevant. The broader ecosystem would benefit from a clear accounting of how module permissions work and what standards apply to third-party integrations.

The Modular Security Problem in Plain Terms

Safe is a smart account platform. Think of it as a shared bank vault that requires multiple keyholders to approve any withdrawal. You need two out of three signatures, or three out of five, before any transaction executes. This is the multisig model, and it is genuinely good security for the core custody function.

Modules are add-ons. They extend what the wallet can do. A module might allow automated recurring payments, or cross-chain routing, or integration with a DeFi protocol. Each module is approved by the wallet owners and given specific permissions to act on the wallet's behalf.

Here is the structural problem. Each module carries its own permissions. Each module may have its own upgrade authority. Each module is its own attack surface. The core vault being secure is not enough if a door you bolted onto the side of it has a broken lock.

This is not a theoretical concern. The SquidRouterModule exploit demonstrated it in practice. According to CryptoTimes, the incident was tied to a fake token scheme that exploited a flaw in the third-party Safe module. The attacker did not need to break Safe's core code. The attacker found a weaker entry point in a component that had been granted permissions to interact with the vault.

For treasury operators and platform builders, this creates a specific audit requirement. It is not enough to know that your core Safe deployment is secure. You need to know, for every active module attached to your wallets: who controls the upgrade keys, what permissions are granted, and when it was last independently audited. If you cannot answer those three questions for every module in your stack today, you have an open exposure.

Pattern Recognition: Three Incidents, Eight Days

This is not an isolated event. In the eight days preceding May 25, 2026, the on-chain custody space recorded three significant incidents. Each one failed at an integration point, not at a core contract.

As I covered three days ago, THORChain lost $10.7 million on May 13, 2026. A malicious node operator exploited a cryptographic key reconstruction scheme called GG20. The core protocol logic was not the failure. The failure was in how the key management system handled a compromised participant at the integration layer between node operators and the vault.

As I covered yesterday, StablR lost $2.8 million on May 24, 2026. Not to a market crash. Not to a code bug. Someone got the keys to a minting multisig. The custody perimeter was breached at the key management layer, not at the contract layer.

Now Squid on May 25, 2026, with $3.2 million gone through a module that had been granted permissions to interact with Safe wallets.

Three incidents. Three different protocols. Three different failure modes. But one consistent pattern: the industry has gotten meaningfully better at auditing core contracts, and it has not kept pace on auditing the connective tissue around them. Bridges, key management schemes, wallet extensions, node operator permissions. These are the integration points where value is moving and where the security posture is weakest.

The aggregate loss across these three incidents alone is approximately $16.7 million in eight days. That number does not include KelpDAO, which I covered eight days ago, where a LayerZero checkpoint configuration failure exposed $293 million. The scale varies, but the structural lesson is the same every time.

For institutional operators, this pattern should trigger a specific response. Not panic. Not a retreat from on-chain infrastructure. A methodical audit of every integration point in your custody stack, starting with the ones that carry the most permissions and ending with the ones that have not been reviewed in the longest time.

Who Should Care

The answer is: more people than are currently paying attention.

If you are a treasury manager running on-chain operations through a Safe-based multisig, this week is your prompt to pull the full list of active modules attached to your wallets. For each one, you need three answers. Who controls the upgrade keys? What permissions does the module hold over the wallet? When was it last audited by an independent security firm? This is not optional hygiene after this week. It is the minimum standard of care for anyone holding institutional funds in a composable wallet stack.

If you are building a tokenization platform, your regulatory exposure does not stop at your core contract. Under MiCA's custody liability provisions, the question regulators will ask is not whether your core code was audited. The question is whether you exercised appropriate due diligence over every component you approved and integrated into your custody infrastructure. A third-party attribution defense may work in a press release. It will not work in a regulatory review.

The same logic applies under ADGM's Digital Assets Framework. The Abu Dhabi Global Market has been building out its digital asset regulatory architecture with custody liability as a central concern. When a regulated entity's wallets lose funds through a component that entity approved, the regulatory question is about the approval process and the ongoing monitoring, not just the technical origin of the exploit.

For institutional RWA platforms specifically, the stakes are higher than for retail DeFi. The funds in these wallets are not speculative positions. They are tokenized real-world assets, treasury instruments, and fund structures where the beneficial owners have fiduciary expectations. A $3.2 million loss through a module that was never properly audited is not just a security incident. It is a breach of the duty of care that institutional operators owe to their clients.

The Counter-Narrative

Skeptics will argue that this incident is being over-read. The loss was $3.2 million, not $3.2 billion. Safe's core infrastructure was not compromised. Squid's protocol was not compromised. The affected wallets were a subset of users who had integrated a specific third-party module, and the broader Safe ecosystem of thousands of wallets was unaffected. The argument goes: modular systems always carry integration risk, this is known, and the solution is better module hygiene, not a structural indictment of composable custody. The skeptic position is that this is a manageable operational risk, not a systemic one.

That argument underestimates the institutional adoption curve. According to Morningstar, Squid had facilitated over $6 billion in cross-chain volume before this incident. As tokenization platforms scale and institutional AUM moves on-chain, the modules attached to Safe wallets will carry larger and larger positions. The $3.2 million loss today is the proof of concept for a much larger exploit tomorrow, and the regulatory frameworks being built right now will be calibrated against incidents like this one.

What to Watch Next

Safe Labs post-mortem. The most important near-term signal is whether Safe Labs publishes a formal post-mortem and what it says. The framing matters. If Safe confirms the module as the sole vector and announces new standards for third-party module permissions or upgrade authority, that sets a new baseline for every platform using Safe infrastructure. If Safe does not publish a detailed post-mortem, the absence of that documentation will be a factor regulators and institutional operators consider when evaluating third-party module standards on the platform.

MiCA and ADGM regulatory response. Watch for supervisory guidance or commentary from either the European Banking Authority under MiCA or ADGM's Financial Services Regulatory Authority referencing modular smart account custody. This incident gives regulators a concrete, named case to tighten custody liability language around composable wallet stacks. The first regulatory body to issue formal guidance citing this event will shape how the entire industry documents and audits third-party module integrations going forward.

Institutional RWA platform disclosures. Watch whether major tokenization platforms using Safe infrastructure publicly disclose module audits, pause third-party integrations, or issue security advisories to their clients in the coming days. The first significant platform to do so will signal how seriously institutional operators are treating the systemic risk here. The platforms that stay silent will face harder questions if a similar incident hits their own wallets.

---

How many teams running institutional funds through Safe-based infrastructure right now could produce a complete, audited list of every active module and its permissions if a regulator asked for it tomorrow?