Squid Router (module impersonation)
An attacker drained 86 Gnosis Safes across Ethereum and Base by tricking the Safe owners into enabling a malicious Safe module that impersonated the SquidRouter brand. Once a Safe enables a module, that module can execute transactions on the Safe's behalf without further owner approval. The attacker waited until enough victims had installed the module, then deployed a drainer contract and walked through every Safe in 14 minutes, pulling out tokens and swapping them to DAI through attacker-controlled Uniswap V3 pools. All proceeds, about 3 million DAI, consolidated into a single wallet. This is not a vulnerability in the legitimate Axelar SquidRouter, which has no involvement.
Squid Router was not scored by our model, and risk scoring cannot prevent users from enabling a phishing module that simply borrows a vendor's name. The relevant defensive layer here is Safe-owner hygiene around module installation, plus wallet-level checks against fresh contract addresses being approved at the enableModule step.
The attacker deployed a malicious Safe module impersonating the Axelar SquidRouter brand. Eighty-six Safe owners were tricked into enabling it on their Safes, likely via a phishing campaign. Hours later, the attacker deployed a drainer contract from their primary EOA and called it 37 times in 14 minutes, walking through every victim Safe and pulling out tokens. Everything got swapped to DAI through attacker-controlled Uniswap V3 pools and consolidated into one wallet holding 3.07M DAI.
Full forensic detail
Step-by-step reconstruction, root cause, counterfactuals, remediation, and disclosure timeline.
Exploit anatomy
enableModule(address)swap routingRoot cause
Once a Gnosis Safe enables a module, that module gains execTransactionFromModule access and can execute arbitrary transactions on the Safe's behalf without further owner approval. This is the documented Safe integration model. The exploit happened because 86 Safe owners enabled an attacker-deployed module believing it was related to the legitimate Axelar SquidRouter. The on-chain pattern is consistent with a phishing campaign that mimicked the SquidRouter brand and walked targets through a flow culminating in enableModule(0xe6ff0fe017...) being signed. Once the attacker had collected enough victims, they deployed a drainer contract and triggered every victim Safe to transfer tokens out within a 14-minute window on Ethereum (and additional time on Base). All stolen tokens were swapped to DAI through attacker-controlled Uniswap V3 pools and consolidated into one wallet. This is not a vulnerability in the legitimate Axelar SquidRouter, which does not require any Safe module installation.
Prevention analysis
If owners had cross-checked 0xe6ff0fe017... against the real Axelar SquidRouter documentation (which does not require any Safe module), the module installation would have been rejected at the signing step.
Brand-new module addresses carry inherent risk. A simple UI warning at the Safe transaction confirmation step would have flagged this module (deployed less than an hour before the attack began).
Once Blockaid identified the malicious module, wallet extensions like Rabby, MetaMask, and Frame can add the address to their phishing block list so future enableModule calls show a warning.
Phishing dApps survive only as long as the user signs immediately. A timelock gives external monitors a window to flag the address before the module activates.
Similar incidents
Signers approved a malicious Safe transaction (February 2025, ~$1.5B). Same lesson: what the signer sees in the UI may not match what executes on chain. Different surface (transaction content vs. module install).
Compromised signer key on a required=1 multisig that controlled mint authority (May 2026, ~$11M). Different mechanism but same operational-security failure family: signers either tricked or compromised.
Remediation
Timeline
Get your protocol scored across 12 dimensions, or request ongoing coverage.