Safe Wallet Third-Party Module Exploit in May 2026

On May 25, 2026, a suspected exploit involving a third-party module connected to Safe wallets resulted in losses of about $3.2 million across Ethereum and Base. The incident was notable not only for the amount taken, but for the speed and concentration of the activity. Blockaid said at least 86 Safe accounts were affected within roughly two hours, indicating a coordinated drain rather than isolated wallet compromises. In the immediate reporting, the event was described as a Safe-related exploit, but the public record quickly narrowed that framing: the issue was presented as stemming from an external module used in connection with Safe accounts, not from Safe’s core wallet architecture itself.

That distinction became central to how the incident was understood. Blockaid identified a contract labeled SquidRouterModule as part of the event, which initially created confusion about whether Squid’s own protocol had been compromised. Squid publicly rejected that interpretation, stating that the issue was unrelated to its core protocol and instead involved a third-party module integrated into Safe wallets. Safe Labs made a parallel clarification. Rahul Rumalla, the company’s CEO, said the affected accounts did not appear to be operated on the official Safe Wallet product and may have been created through externally deployed integrations. Taken together, those statements place the apparent failure at the integration layer: a module or surrounding deployment path appears to have introduced the vulnerability, while the underlying Safe system was described as unaffected.

The on-chain pattern reported in the aftermath also fits a familiar exploitation sequence. According to Blockaid, the stolen tokens were swapped into DAI through attacker-controlled Uniswap V3 pools. In practical terms, that means the attacker did not simply remove assets from the affected accounts; the assets were rapidly converted into a single token through liquidity venues under the attacker’s control. This kind of routing can reduce exposure to price volatility across multiple stolen assets and can also simplify subsequent fund handling. The data cited in reporting does not establish recovery, and no recovery percentage was disclosed in the brief. What it does establish is a compressed operational window, cross-chain impact spanning Ethereum and Base, and a post-theft conversion path that suggests the attacker moved quickly to standardize the proceeds.

From a control perspective, the event highlights two structural weaknesses identified in the brief: single-point-of-control and the absence of withdrawal monitoring. Safe is widely used because it supports modular account design, but modularity also creates a boundary problem: trust can shift from the core wallet logic to optional components or external integrations that do not share the same security assumptions. If a module can authorize or facilitate transfers in a way users do not fully observe, the practical effect is that one external component may become the decisive control point over funds. The speed of the drain across dozens of accounts further suggests that once the exploit path was available, there was limited friction to stop or flag abnormal outflows in real time. Even without evidence of a flaw in Safe’s core protocol, the incident shows how security failures can emerge at the edges of a wallet system, where naming overlap, third-party deployment practices, and delegated permissions can obscure where responsibility actually sits.