Een
exploit via een externe Safe-module heeft minstens 86 wallets op Ethereum en Base geraakt. Volgens Blockaid werd op 25 mei in ongeveer twee uur tijd circa $3 miljoen buitgemaakt via een contract dat als SquidRouterModule stond gelabeld, terwijl Squid stelt dat zijn core-protocol en routercontracten niet zijn getroffen.
De eerste verwarring ontstond door de naam van het contract. Omdat het label “SquidRouterModule” gebruikte, leek het incident in eerste instantie met Squid zelf te maken te hebben. Squid reageerde snel en stelde dat het om een derdepartijmodule ging, niet om Squid’s eigen Router-contract.
Blockaid meldt 86 getroffen Safe-wallets
Blockaid detecteerde de exploit op Ethereum en Base. Volgens het securitybedrijf werden 86 Gnosis Safe-wallets in ongeveer twee uur leeggetrokken, waarna de buitgemaakte tokens werden omgezet naar DAI via door de aanvaller gecontroleerde Uniswap V3-pools.
Secundaire berichtgeving noemt een totale schade van ongeveer $3 miljoen tot $3,2 miljoen. Crypto.news schrijft dat de opbrengst uiteindelijk werd geconsolideerd in één wallet met iets meer dan 3,07 miljoen DAI.
Dat wijst op een strak uitgevoerde aanval. De aanvaller gebruikte niet alleen een kwetsbare module, maar had ook routing en consolidatie voorbereid om snel uit verschillende tokens naar één stabiele asset te bewegen.
Squid zegt dat core-protocol niet geraakt is
Voor Squid was de eerste prioriteit duidelijk: afstand nemen van de exploit. Het protocol benadrukte dat de aangevallen module niet door het eigen team was geschreven of gedeployd. Volgens Squid ging het om een derdepartij smart-walletmodule die met meerdere protocollen kon integreren, waaronder Squid.
Die nuance is belangrijk. Het incident betekent niet dat Squid’s core-router of cross-chain protocol is leeggetrokken. Het betekent ook niet dat alle Squid-gebruikers actie moesten ondernemen.
De juiste lezing is specifieker: bepaalde Safe-wallets die deze externe module eerder hadden toegestaan of gebruikt, werden kwetsbaar door de bevoegdheden die de module kreeg.
Module-rechten worden de zwakke plek
Het incident raakt een bredere les voor DeFi-treasuries en smart-walletgebruikers. Safe-wallets worden vaak gebruikt voor multisigs, DAO’s, teamtreasuries en professioneel self-custodybeheer. Juist daarom worden ze uitgebreid met modules, automatisering en integraties.
Die extra functionaliteit heeft een prijs. Een module kan rechten krijgen om transacties uit te voeren, swaps te routen of handelingen namens de wallet te verrichten. Als zo’n module kwetsbaar is, verschuift het risico van de multisig zelf naar de extra bevoegdheidslaag erbovenop.
Volgens meerdere analyses konden aanvallers via de kwetsbare module transacties uitvoeren alsof zij een vertrouwde delegate waren. Daarbij werden fake of door de aanvaller gecontroleerde Uniswap V3-swaps gebruikt om assets uit wallets naar DAI om te zetten.
Dat maakt dit incident ernstiger dan een gewone tokenapproval. Het gaat om gedelegeerde uitvoeringsmacht binnen smart-walletinfrastructuur.
Geen bewijs dat Safe-core is gebroken
Ook hier is nuance nodig. Het incident laat niet zien dat Safe als core-walletmodel fundamenteel is gebroken. Het laat zien dat externe modules, als zij te ruime rechten hebben of onvoldoende veilig zijn, het beveiligingsmodel van een Safe kunnen ondermijnen.
Dat onderscheid is belangrijk voor gebruikers. Multisigbeveiliging helpt weinig als een eerder toegestane module zelfstandig schadelijke transacties kan uitvoeren.
Voor DeFi-teams is de les dus niet: stop met Safe. De les is: behandel modules als kritieke code, niet als handige add-ons.
Wat gebruikers nu moeten controleren
Safe-gebruikers die met externe modules werken, moeten controleren welke modules actief zijn, welke rechten die modules hebben en of er onbekende delegates, hooks of automationroutes zijn ingesteld.
Vooral wallets die ooit met cross-chain routing, swapmodules, automatisering of treasurytools hebben gewerkt, moeten hun modulelijst opnieuw nalopen. Onbekende of ongebruikte modules moeten worden verwijderd, maar alleen na zorgvuldige controle om geen operationele afhankelijkheden te breken.
Teams moeten ook transaction history, module enablement events en recente tokenbewegingen op Ethereum en Base controleren. Als een wallet tekenen van exposure heeft, moeten resterende assets worden verplaatst naar een nieuwe, schone Safe met minimale modules en opnieuw ingestelde signers.
Breder signaal voor DeFi-security
De exploit past in een grotere verschuiving. Veel DeFi-security focust op protocolcontracten, bridges en front-ends. Maar smart-walletmodules worden steeds belangrijker omdat zij meerdere protocollen, chains en treasuryprocessen verbinden.
Dat maakt ze aantrekkelijk voor aanvallers. Een kwetsbare module kan toegang geven tot meerdere wallets tegelijk, zonder dat de aanvaller elk protocol afzonderlijk hoeft te breken.
Voor de markt is nu vooral belangrijk of dit incident beperkt blijft tot deze specifieke SquidRouterModule, of dat vergelijkbare externe modules met ruime rechten ook extra risico dragen.
De kern: minder vertrouwen in add-ons
Het belangrijkste gevolg is reputatie- en risicobewustzijn. Safe blijft een belangrijke infrastructuurlaag voor self-custody en treasurybeheer, maar dit incident toont dat de beveiliging van een smart-wallet net zo sterk is als de modules die eraan hangen.
Voor DAO’s, fondsen en teams wordt modulebeheer daarmee een vast onderdeel van security. Niet alleen signers, multisigs en hardware wallets moeten worden gecontroleerd, maar ook externe modules, delegates, automation tools en oude integraties.
De conclusie is nuchter. Dit was geen bewezen exploit van Safe-core en ook geen exploit van Squid’s core-protocol. Het was een aanval via een externe module met genoeg rechten om echte schade te veroorzaken. Precies dat maakt het incident relevant: de volgende DeFi-exploit hoeft niet in het hoofdcontract te zitten, maar kan binnenkomen via de handige uitbreiding die ooit aan de wallet is toegevoegd.