Squid said on May 25, 2026, that a third-party module named SquidRouterModule was exploited, resulting in approximately $3.2 million in losses across Safe wallets on Ethereum and Base. The protocol emphasized that the incident did not involve Squid’s core router contract or official protocol infrastructure, and said its users and integrators were unaffected.
Blockchain security firm Blockaid said the exploit affected 86 Gnosis Safe wallets over roughly two hours, with stolen assets converted into DAI through attacker-controlled Uniswap V3 pools. The attacker consolidated about $3.07 million into a single wallet after the drain, making the loss estimate based on on-chain tracing rather than a user-balance compromise inside Squid itself.
🚨 Blockaid detected an ongoing exploit targeting the SquidRouterModule on Ethereum and Base.
86 Gnosis Safes drained for ~$3M in ~2 hours.
All stolen tokens swapped to DAI via attacker-controlled Uniswap V3 pools.
More details in 🧵— Blockaid (@blockaid_) May 25, 2026
Third-Party Module, Not Squid’s Router Contract
The distinction matters because Squid’s official router address is 0xce16F69375520ab01377ce7B88f5BA8C48F8D666, listed in Squid’s own documentation as its SquidRouter contract across EVM chains. Squid said the exploited module shared the SquidRouterModule name but was not its production router architecture or code.
According to technical summaries citing Blockaid, the vulnerability was tied to the module’s executeSameChainActions() function and weak identity validation. The module allegedly accepted a caller-supplied fixed string as a security confirmation, allowing attackers to pass arbitrary calldata once the module had been added as trusted by affected Safe wallets.
This incident is unrelated to Squid’s core protocol and contracts. All Squid users and integrators are unaffected and no action is needed.
A third-party Gnosis Safe module was exploited today across Base and Ethereum, resulting in approximately $3.2M in losses. The vulnerable… https://t.co/I3gGmdBvE9
— squid (@squidrouter) May 25, 2026
That permission model is the operational root of the incident. Safe modules can execute actions on behalf of a wallet after being granted authority, so a vulnerable trusted module can bypass the protection users expect from normal multisig approvals.
Wallet-Level Permissions Became the Attack Surface
The exploit appears to have targeted wallets that had enabled the third-party module, not Squid’s core routing layer. Safe Labs CEO Rahul Rumalla said the affected accounts did not appear to be operated through the official Safe Wallet product and were likely created through external integrations, reinforcing the wallet-integration nature of the risk.
For affected users, the key issue is module exposure. Reports citing the incident advised users with the SquidRouterModule enabled to remove or revoke it, because the immediate risk sits with wallets that granted execution permissions to the vulnerable module, not with every Squid user.
The confirmed development remains narrow: a third-party Safe module named SquidRouterModule was exploited, 86 Safe wallets were drained across Ethereum and Base, and the stolen assets were routed into DAI. Squid’s official position is that its core protocol, official router contract, users and integrators were not affected, while the incident highlights the continuing security burden created by external wallet modules and delegated execution paths.