Worked example · 2026-05

SquidRouterModule — counterfeit Safe module with public-constant-string "authorization" — 2026-05-25

Loss: ~$3.2M drained from 86 Gnosis Safe wallets in about two hours across Ethereum and Base; the attacker converted the proceeds into roughly 3.07M DAI. The losses fell on individual Safe owners who had enabled a third-party module named "SquidRouterModule" — a contract that was not built, deployed, or operated by the cross-chain protocol Squid, whose own router contracts and user funds were unaffected.
OAK Techniques observed: OAK-T9.004 (Access-Control Misconfiguration — the canonical anchor. The module accepted a publicly-known constant string as proof of authorization, so any caller could present that constant and have the module execute arbitrary transactions on a victim Safe with no valid owner signature. The "authorization" was a public constant, i.e. no authorization at all. See techniques/T9.004-access-control-misconfiguration.md). OAK-T11.003 (In-Use Multisig Smart-Contract Manipulation — cross-referenced: a Safe module is an extension with authority to execute transactions on the Safe's behalf, bypassing the owner-signature threshold; the attacker used the malicious module as an authorised delegate to move funds the multisig's signature policy was supposed to protect). OAK-T6.006 (Counterfeit Token / Brand Impersonation — cross-referenced: the contract was verified on Basescan under the name "SquidRouterModule," borrowing the Squid brand to appear legitimate; reporting tied it to a fake-token scheme).
Attribution: pseudonymous attacker; deployer unknown (Squid stated "we don't know who deployed this"). Blockaid detected the exploit. The drain wallets and the ~3.07M DAI consolidation are observable on Ethereum and Base. No public attribution to a named operator group.
Key teaching point: SquidRouterModule is the 2026 worked example of a counterfeit Safe module whose "authorization" was a public constant — the most basic access-control failure (auth-by-shared-secret-that-isn't-secret) wrapped in a brand-impersonating package and installed by victims onto their own multisigs. Two compounding failures produced the loss: (1) a module with no real authorization — it gated privileged execution behind a constant string that anyone could read off-chain and replay, so possession of a "secret" that was public granted full delegate authority; and (2) users enabling an unaudited, brand-impersonating third-party module on a Safe, which grants that module authority to move funds without further owner signatures. The detection-signal locus is the Safe-module-enablement layer: enabling a module is a privilege grant equivalent to adding a signer, and any module — especially one impersonating a known brand — must be audited and verified-authentic before it is enabled, because once enabled it can bypass the very signature threshold the multisig exists to enforce.

Summary

A Gnosis Safe module is a smart contract that, once enabled by a Safe's owners, can execute transactions on the Safe's behalf without going through the normal owner-signature threshold. Modules are powerful by design — they exist to let trusted automation (recurring payments, recovery flows, routing) act for the Safe — which is exactly why enabling one is a high-privilege action.

On 2026-05-25, Blockaid detected an exploit targeting a module named "SquidRouterModule" that had been enabled on 86 Safe wallets. The module's authorization check accepted a publicly-known constant string as proof that the caller was permitted to act. Because that constant was not secret, any attacker could present it and have the module execute arbitrary transactions on every Safe that had enabled it. The attacker used this to masquerade as an authorised delegate and drained ~$3.2M across Ethereum and Base in about two hours, executing fake Uniswap V3 swaps to move and consolidate value, ultimately converting the proceeds into roughly 3.07M DAI.

The contract was verified on Basescan under the "SquidRouterModule" name, but the cross-chain protocol Squid publicly distanced itself: it did not build, deploy, or operate the module, its core router contracts were unaffected, and it stated it did not know who deployed the lookalike. Reporting tied the module to a fake-token scheme used to induce victims to enable it.

Why this is structurally significant

SquidRouterModule sits at the intersection of three failures that the corpus usually treats separately, and the combination is the lesson:

Non-authorization disguised as authorization (T9.004). Gating privileged execution behind a public constant is the canonical "auth that isn't auth" anti-pattern. It is the module-level analogue of a missing onlyOwner modifier (KiloEx) or a permissionless privileged function (TrustedVolumes, Sweat Foundation): the function looks gated, but the gate is satisfiable by anyone. Recording it precisely matters — this is not a stolen key or a forged signature; it is an authorization predicate that grants access to all comers.
Module authority bypasses the multisig threshold (T11.003). The reason a module failure is catastrophic is that an enabled module can move funds without owner signatures. The victims' Safes may have had robust m-of-n signing policies — and the module rendered them irrelevant, because the module was itself an authorised execution path. This is the same "the signatures were never the problem" insight as the Superfortune destination-tampering and Bybit signing-flow cases, but reached through a module rather than a corrupted signing UI.
Brand impersonation as the install lure (T6.006). Naming the contract "SquidRouterModule" and tying it to a fake-token scheme is what got victims to enable it. The Squid brand supplied the trust that a raw, unknown module would not have. This is the counterfeit-contract analogue of counterfeit-token impersonation: the attacker did not compromise Squid; they wore Squid's name to get users to grant a malicious module Safe-level authority.

The composition — brand-impersonation lure → user enables module → module's "auth" is a public constant → module drains the Safe past its signature threshold — is a repeatable template against the entire Safe-module ecosystem. As Safe modules proliferate for automation and account-abstraction flows, "what modules are enabled on this Safe, who authored them, and how do they authorise callers?" becomes a first-order custody question.

Timeline (UTC)

When	Event	OAK ref
Pre-2026-05-25	A third-party contract named "SquidRouterModule" (not built/deployed by Squid) is verified on Basescan; victims are induced — reportedly via a fake-token scheme — to enable it as a module on their Safes	T6.006 (brand-impersonation lure), module-enablement (privilege grant)
2026-05-25	Attacker presents the module's publicly-known constant string as "authorization," masquerading as an authorised delegate, and executes arbitrary transactions on the 86 Safes that enabled it	T9.004 (public-constant authorization bypass), T11.003 (module bypasses owner-signature threshold)
2026-05-25 (~2h)	Attacker drains ~$3.2M across Ethereum and Base via fake Uniswap V3 swaps; converts proceeds to ~3.07M DAI	T5 outflow
2026-05-25	Blockaid detects and reports the exploit; Squid distances itself ("we don't know who deployed this"); core Squid router contracts and user funds confirmed unaffected	(third-party detection / operator clarification)

What defenders observed

Pre-event (module-enablement layer): victims enabled an unaudited, brand-impersonating third-party module on their Safes. Enabling a module grants it authority to execute without owner signatures — a privilege grant equivalent to adding a signer. Defender lesson: treat module enablement as a high-risk action; verify the module's authorship and audit status, and prefer modules whose source and deployer are cryptographically tied to the genuine brand.
At-event (authorization signal): the module authorised callers by checking a public constant string. A pre-enablement review of the module's access-control logic would have surfaced that the "authorization" was satisfiable by anyone. The on-chain signal — a single non-owner caller invoking a module to execute swaps across many distinct Safes in a short window — is a strong "module-as-delegate abuse" pattern that a Safe-monitoring service could flag.
At-event (brand signal): a Basescan-verified contract named after a well-known protocol, but not deployed from that protocol's known deployer, is a counterfeit-contract signal. Brand-name verification is not authorship verification.
Post-event (consolidation): proceeds were converted to ~3.07M DAI, the standard stablecoin-consolidation step. Squid's public clarification (unaffiliated lookalike) is itself a recurring forensic artefact — a named brand disowning a counterfeit contract that traded on its name.

What this example tells contributors writing future Technique pages

"Public constant as authorization" is a recordable T9.004 sub-shape. It is distinct from a missing modifier (KiloEx) and a permissionless function (Sweat Foundation): the predicate exists and looks like auth, but the secret it checks is public. Record it explicitly; the detection guidance ("is the gating value actually secret / actually bound to the caller's identity?") is specific.
Safe-module enablement is a custody-grade privilege grant. T11.003 should cover not only manipulation of the multisig contract itself but the enablement of a malicious module that bypasses the signature threshold. The mitigation (audit + authorship verification before enabling, periodic module-inventory review) belongs in the T11.003 / custody guidance.
Counterfeit contracts extend T6.006 beyond counterfeit tokens. A contract verified under a known protocol's name, but deployed by an unrelated party, is brand impersonation at the contract layer. Record "Basescan/Etherscan name ≠ authorship" as a counterfeit-contract signal.
Record the install lure separately from the exploit primitive. The fake-token scheme that induced enablement (T6.006) and the public-constant auth bypass (T9.004) are distinct stages; both are needed for the loss and both have distinct mitigations.

Public references

The Block — "We don't know who deployed this": Squid distances itself from $3.2 million third-party module exploit
Coinpedia — $3M Drained from 86 Gnosis Safes in SquidRouterModule Exploit
BeInCrypto — Squid Distances Itself From $3.2 Million Hack of Lookalike Third-Party Contract
crypto.news — Squid rushes to separate brand from $3 million Gnosis Safe module exploit
Crypto Times — Gnosis Safe Users Hit by $3M Exploit Tied to Fake Token Scheme — module accepted a publicly known constant string as proof of authorization; ~3.07M DAI consolidation. Detection by Blockaid.

Discussion

SquidRouterModule is the corpus's clearest 2026 case of Safe-module risk: a custody surface that grows as Safe modules become standard automation and account-abstraction primitives. The exploit primitive was elementary — authorization by a public constant, the "auth that isn't auth" failure that also defines KiloEx, TrustedVolumes, and Sweat Foundation — but its reach came from the module being an enabled delegate that bypassed each victim Safe's owner-signature threshold, and its distribution came from impersonating the Squid brand to induce enablement.

The case pairs naturally with Superfortune (examples/2026-05-superfortune-gua-multisig-destination-tampering.md) as two May-2026 multisig-custody failures where the owners' signatures were never the weak point: Superfortune diverted a signed transaction's destination; SquidRouterModule used an enabled module to act without signatures at all. Together they argue that multisig security in 2026 depends as much on what authority has been delegated away from the signature threshold — destinations, modules, automation — as on the threshold itself. The actionable controls are pre-enablement module audits, authorship verification against the genuine brand's deployer, and periodic review of which modules a Safe has enabled.