In May 2026, SquidRouterModule, a third-party Gnosis Safe module that interfaces with Squid Router on Base and Ethereum, was the victim of a hack. The attacker exploited a vulnerability in the module’s smart contract to steal an estimated $3.2 million from 86 Gnosis Safe wallets over the course of two hours.
Inside the Attack
The SquidRouterModule hack was made possible by a verification error within the contract’s executeSameChainActions() function. The contract was configured with a fixed string embedded in the contract code that is provided by the caller to identify “safe messages”.
The SquidRouterModule smart contract is verified on BaseScan, meaning that the source code of the contract is publicly available. As a result, anyone could review the source code and extract the fixed string that the function used for verification. The attacker did so, allowing them to make transactions with arbitrary calldata to the vulnerable function.
With access to the fixed string, the attacker could impersonate the legitimate owners of various Gnosis Safe wallets. This was dangerous because Gnosis Safe modules are permitted to perform transactions without explicit validation by their owners. The SquidRouterModule already had all of the permissions needed to drain funds from the wallets of users who enabled it.
The attacker targeted 86 Gnosis Safe wallets that had installed SquidRouterModule. In total, they were able to drain an estimated $3.2 million, swap it using attacker-controlled Uniswap V3 pools to an attacker-created token “u”, remove liquidity from the pools, and consolidate into over $3 million worth of DAI.
Lessons Learned from the Attack
The SquidRouterModule hack demonstrates the risks associated with granting privileges to smart contracts, especially third-party ones. Despite its name, SquidRouterModule has no official relationship with Squid and the Squid Router. Users who installed the module and granted it the necessary privileges were placing their trust in it to be secure and not malicious.
The SquidRouterModule smart contract was verified on BaseScan, which is usually a good sign. However, the fact that the source code is publicly available doesn’t mean that it’s secure or has been audited. In this case, open source code made things worse by making it trivial for an attacker to collect the fixed string needed to defeat the module’s weak verification.
When implementing on-chain identity verification, it’s important to design protocols based on security best practices and ensure that all code is audited before deployment on-chain. Halborn offers security advisory services and smart contract reviews to help protect your project. Get in touch to find out more.