Săptămâna a început prost pentru câteva zeci de utilizatori avansați de criptomonede care credeau că folosesc una dintre cele mai sigure configurații multi-semnătură din DeFi.
Pe 25 mai 2026, un atacator a profitat de o vulnerabilitate într-un modul publicat pe Ethereum și pe Base sub numele SquidRouterModule și a scos aproximativ 3,2 milioane de dolari din 86 de portofele Gnosis Safe. Tot procesul a durat sub două ore. Majoritatea victimelor nu au mai apucat să facă nimic.
Numele contractului a aprins aproape imediat confuzia. SquidRouterModule sună a componentă oficială a protocolului Squid, un sistem de rutare cross-chain cunoscut, folosit pentru transferul activelor între rețele blockchain diferite. Lucrurile arătau însă altfel.
Modulul vulnerabil nu fusese scris de echipa Squid și nu purta nicio amprentă a acesteia. Apăruse pe blockchain ca produs al unei terțe părți care a ales să-și boteze creația cu un nume împrumutat.
Un nume care a creat confuzie pe Ethereum și Base
Modulul rula deja pe ambele rețele, autorizat în 86 de portofele Safe diferite. Conturile aparțineau unei game variate de utilizatori, de la persoane fizice cu portofele consistente până la echipe care administrau capital comun prin structuri multi-semnătură. Toate aveau însă un punct comun. Aprobaseră modulul ca având drepturi de execuție directă, fără să mai fie nevoie de semnături suplimentare la fiecare tranzacție.
Decizia părea inofensivă la momentul aprobării. S-a transformat însă, peste noapte, în punctul slab al întregii structuri. Atacatorul a parcurs sistematic lista portofelelor care permiseseră accesul contractului și le-a drenat metodic, una după alta. O configurație considerată ani la rând drept exemplul de bună practică în autocustodie a devenit, în mai puțin de o sută de minute, o țintă predictibilă.
Cum a derulat atacatorul golirea celor 86 de portofele
Firmele de securitate Blockaid și PeckShield au raportat incidentul în timp real și au oferit o cronologie clară a evenimentelor. În aproximativ două ore, fondurile au fost scoase, schimbate și consolidate într-un singur portofel. Viteza operațiunii a făcut imposibil orice răspuns coordonat din partea victimelor sau a comunității de white hats care, în alte cazuri recente, reușise să blocheze fonduri prin tranzacții preventive.
Atacatorul a folosit instrumente bazate pe Foundry, un framework de dezvoltare Ethereum popular printre programatori cu experiență, pentru a publica contracte de exploit. Aceste contracte apelau funcția DelegateBundler a modulului vulnerabil și se prezentau drept delegați autorizați. Sistemul vedea apelurile ca venind din partea unor utilizatori cu drepturi de execuție, deși în realitate veneau de la o adresă complet străină.
Mecanismul amintește îndeaproape de alte exploituri prin vulnerabilități de autorizare care au lovit ecosistemul în ultimele luni, unde validarea precară a deschis ușa unor atacuri pe care orice utilizator obișnuit putea, teoretic, să le execute.
Analiza independentă publicată de Blockaid a localizat vulnerabilitatea în funcția executeSameChainActions(). Acea funcție permitea execuția neautorizată în interiorul conturilor Safe. Combinația dintre validarea defectuoasă și autoritatea acordată modulului a creat o gaură de securitate suficient de mare cât să dreneze 86 de Safe-uri într-un interval extrem de scurt.
Reacția echipei Squid și delimitarea publică
Co-fondatorul pseudonim Fig a intervenit public pe X cu o formulare neobișnuit de directă pentru un anunț corporativ din zona cripto. Contractul denumit SquidRouterModule nu are nicio legătură cu protocolul Squid, iar echipa nu știe nici acum cine a scris sau cine a publicat codul.
Pagina oficială a proiectului a confirmat poziția cu o explicație suplimentară. Router-ul principal al protocolului este separat arhitectural de modulul compromis și nu a fost atins în niciun moment.
Detaliile complete ale incidentului au fost reconstituite și relatate de Cryptology.ro, publicația românească de știri și analize cripto, într-un material amplu semnat de Mihai Popa, jurnalist și analist cu experiență în descifrarea atacurilor on-chain.
Articolul original a punctat un detaliu care, de regulă, scapă presei generaliste. Relatările timpurii care făceau referire la „SquidRouter” erau tehnic inexacte. Contractul împărtășea doar numele Squid, fără să aibă vreo legătură contractuală sau de cod cu echipa oficială.
Genul ăsta de delimitare publică este rar întâlnit într-o industrie în care brandurile și componentele se împrumută adesea într-un mod neformalizat. Cazul scoate la suprafață o problemă structurală a ecosistemului.
Oricine poate publica un contract pe Ethereum sau Base, îl poate denumi cum dorește și îl poate verifica pe exploratoare precum Basescan. Faptul ăsta creează aparența unei legături oficiale între un protocol cunoscut și o componentă independentă pe care echipa originală nu a autorizat-o niciodată.
Anatomia tehnică a vulnerabilității
Detaliile codului oferă o lecție de manual despre ce nu trebuie făcut într-un contract inteligent. Modulul vulnerabil accepta un șir constant, furnizat chiar de apelant, drept dovadă că un mesaj era securizat.
Cu alte cuvinte, oricine cunoștea acel șir putea convinge codul că tranzacția lui era legitimă. Codul fiind public, șirul putea fi citit direct de pe blockchain de orice persoană capabilă să descifreze Solidity la un nivel mediu.
Trecerea acestui șir simplu permitea atacatorului să execute calldata arbitrară și să cheltuiască orice token aflat în portofelele Safe vulnerabile, fără să fie nevoie de semnături. Mecanismul de protecție era echivalent cu o ușă încuiată, doar că autorul codului lăsase cheia atârnată într-un cui chiar pe ușa respectivă.
O greșeală pe care orice auditor o repera
Eroarea fundamentală a fost dezarmant de simplă. Validarea bazată pe un șir constant public reprezintă unul dintre cele mai elementare antipattern-uri din scrierea de contracte inteligente. Programatorii cu experiență în Solidity recunosc imediat tipul de eroare.
Și totuși, modulul a fost publicat în producție, adoptat de zeci de utilizatori sofisticați și a rămas activ suficient timp cât atacatorul să descopere problema și să o exploateze metodic.
Detaliul sugerează că modulul nu a trecut printr-un audit profesional sau, dacă a trecut, raportul auditorilor a fost ignorat de cei care l-au integrat.
Sunt și alte cazuri în care atacuri DeFi de proporții au pornit de la o singură funcție prost validată, ceea ce arată că practica auditării superficiale rămâne o vulnerabilitate sistemică. În cazul unui modul cu acces direct la fondurile portofelelor multisig, neglijența pare aproape de neconceput. Și totuși s-a întâmplat, iar consecințele sunt vizibile pentru oricine deschide Basescan.
Traseul fondurilor furate prin Uniswap V3
Atacatorul a urmat un tipar deja familiar în lumea exploiturilor DeFi. Activele scoase din portofele, printre care stablecoini precum USDC și USDT, alături de tokenul ENA, au fost dirijate prin pool-uri Uniswap V3 controlate chiar de el. În acele pool-uri așezase deja un token fără valoare creat în prealabil, denumit simplu „u”.
Mecanismul are ingeniozitatea lui, văzut din perspectiva atacatorului. Schimbând activele valoroase furate cu acest token „u” prin pool-uri pe care le controla, atacatorul obținea efectiv lichiditate proprie. După aceea, retrăgea lichiditatea, păstrând activele reale și aruncând tokenul fără valoare înapoi în pool.
Manevra îi permite uneori să eludeze filtrele automate care monitorizează adresele cu transferuri directe către exchange-uri sau mixere cunoscute. Un atac similar asupra Aperture Finance a folosit, la începutul anului, o tehnică apropiată pentru a obscuriza urma fondurilor înainte de încercarea de cash-out.
PeckShield a confirmat că, după toate aceste mișcări, fondurile au fost consolidate într-o singură poziție de aproximativ 3,07 milioane DAI, depusă într-un portofel cu adresa începând cu 0xa447.
Adresa atacatorului propriu-zis a fost identificată drept 0x9bdc730183821b6bb2b51be30b77c964fa645b91, iar Etherscan a înregistrat aproximativ 52 de tranzacții legate de operațiune în ziua atacului. Finanțarea inițială a contului a venit din Tornado Cash sub forma a 2,1 ETH, un detaliu care nu surprinde pe nimeni din ecosistem.
Pregătirea făcută prin acest mixer indică un nivel de premeditare considerabil, nu o reacție improvizată.
De ce modulele Safe rămân un punct slab al DeFi
Mecanismul atacului devine inteligibil doar privind cum funcționează portofelele Safe. Spre deosebire de un portofel obișnuit, Safe este o structură multi-semnătură care permite mai multor utilizatori să controleze fondurile împreună.
Pe lângă semnăturile clasice, sistemul permite și conceptul de modul. Un modul este un contract inteligent extern căruia proprietarii portofelului îi acordă permisiunea de a executa tranzacții fără semnături suplimentare.
Funcționalitatea servește unui spectru larg de scenarii, de la automatizări recurente până la integrări complexe între protocoale DeFi. Când un proprietar aprobă un modul, el deleagă o parte din autoritate către codul acelui modul. Dacă modulul este bine scris, totul funcționează corect. Dacă modulul are o vulnerabilitate, fondurile pot fi golite chiar dacă portofelul în sine nu a fost compromis criptografic. Tocmai asta s-a întâmplat cu cele 86 de portofele care folosiseră SquidRouterModule.
Cea mai apropiată comparație pentru cititorii nefamiliarizați cu termenii blockchain vine din lumea aplicațiilor mobile cu permisiuni. Când un utilizator instalează o aplicație pe telefon și îi acordă acces la contacte, fotografii sau locație, el îi deleagă acelei aplicații o parte din controlul asupra propriilor date. Modulele Safe funcționează după un principiu similar, doar că miza este una financiară directă și ireversibilă.
Odată ce un modul are permisiunea de a executa tranzacții pe Safe, el o poate folosi cum dorește. Iar dacă acel cod a fost scris greșit sau cu intenții malițioase, fondurile pleacă undeva și foarte rar mai pot fi recuperate. Compromiterea portofelelor crypto prin canale mai puțin evidente a devenit o constantă a anului, iar lecția modulelor Safe se aliniază perfect acelui tipar mai larg.
Un context dificil pentru securitatea DeFi în 2026
Incidentul SquidRouterModule se adaugă unui an deja apăsător pentru securitatea DeFi. Datele agregate publicate de The Block arată că pierderile cumulate din 2026 au depășit deja 770 de milioane de dolari, iar doar aprilie a marcat un record nedorit, cu aproximativ 30 de incidente și peste 630 de milioane de dolari sustrași într-un singur interval.
Pe măsură ce ecosistemul atrage capital instituțional, atacatorii descoperă vectori mai sofisticați, iar țintele cresc proporțional în valoare. Modulele de la terți, podurile cross-chain și agregatorii de lichiditate au fost constant printre cele mai expuse componente, tocmai pentru că agregă fonduri din mai multe surse și interacționează cu mai multe contracte deodată.
La acest tablou s-au adăugat și breșe în infrastructura de dezvoltare software care au demonstrat că vectorii de atac depășesc demult granițele clasice ale codului on-chain.
Reconstituirea atacului și a traseului fondurilor a fost realizată de Mihai Popa, editorialist și specialist în atacuri on-chain la Cryptology.ro, una dintre cele mai active surse de stiri cripto din spațiul românesc.
Coincidența ironică, semnalată în analiza originală, este că Squid tocmai anunțase o rundă de finanțare strategică de 6 milioane de dolari, condusă de North Island Ventures. Cu finanțarea proaspătă vine și o creștere a atenției publice, iar acum echipa trebuie să dedice timp prețios apărării brandului împotriva confuziei generate de un cod pe care nu l-a scris niciodată.
Pentru un proiect aflat în creștere, situația reprezintă o povară reputațională serioasă, chiar dacă din punct de vedere tehnic echipa nu poartă nicio responsabilitate.
Lecția despre identitate și încredere în lumea on-chain
Atacul are o latură instructivă dincolo de partea pur tehnică. Niciun cod al protocolului Squid nu a fost compromis. Niciun utilizator care interacționa cu Squid prin canalele oficiale nu a pierdut bani. Și totuși, 86 de Safe-uri au fost golite pentru că proprietarii lor au luat o singură decizie greșită, aprobând un modul de la o terță parte fără o verificare profundă a acestuia. Tendința nu este nouă.
Stablecoini compromiși prin exploituri tehnice sau active sustrase prin agregatori prost auditați au alcătuit, în ultimele luni, un șir de incidente care vorbesc despre aceeași slăbiciune fundamentală a ecosistemului.
Adevărul scoate în evidență o problemă pe care comunitatea cripto o discută rar cu seriozitate. Securitatea în DeFi nu este o proprietate a unui singur protocol. Este o proprietate a întregii configurații pe care fiecare utilizator și-o construiește. Un Safe perfect securizat poate fi golit prin intermediul unui modul prost. O cheie privată bine păstrată nu protejează împotriva unei aprobări nesăbuite acordate unui contract malițios.
Cazul SquidRouterModule rămâne o lecție despre cât de puțin contează un nume pe blockchain atunci când vine vorba de securitate. Două contracte pot purta nume aproape identice și pot face lucruri complet diferite. Verificarea pe exploratorul de blockchain confirmă doar că respectivul cod sursă corespunde bytecode-ului implementat, nu și că autorul este cine pretinde că este sau că acel cod este sigur.
Aprobarea unei tranzacții sau a unui modul ar trebui să implice verificarea identității dezvoltatorului prin canale oficiale ale protocolului, nu prin recunoașterea unui nume familiar pe un explorator.
Squid a comunicat că vor urma mai multe informații pe măsură ce investigația avansează. Niciun calendar nu a fost anunțat, iar acțiunile concrete nu au fost încă detaliate, ceea ce lasă comunitatea într-un stadiu de așteptare. Pentru utilizatorii care au pierdut bani, perspectiva este una limitat reconfortantă.
Cei 3,2 milioane de dolari rămân în portofelul atacatorului, sub formă de DAI gata să fie mutați în orice clipă. Protocolul de bază al Squid continuă să funcționeze, neatins de eveniment.
Undeva pe blockchain însă, un nume care nu aparținea oficial nimănui a generat o vulnerabilitate care arată cât de fragilă este granița dintre brand și cod în DeFi-ul de astăzi.