Săptămâna a început prost pentru câteva zeci de utilizatori avansați de criptomonede, oameni convinși că folosesc unul dintre cele mai sigure tipuri de portofel disponibile pe blockchain.
Luni, 25 mai, un atacator a profitat de o vulnerabilitate într-un modul publicat pe Ethereum și Base sub numele SquidRouterModule și a scos aproximativ 3,2 milioane de dolari din 86 de portofele Gnosis Safe. Operațiunea s-a derulat în mai puțin de două ore, iar majoritatea victimelor nu au mai apucat să facă nimic.
Numele contractului a creat imediat confuzie. SquidRouterModule sună a componentă oficială a protocolului Squid, un sistem cunoscut de rutare cross-chain folosit pentru a muta active între rețele blockchain diferite. Lucrurile stăteau însă altfel, iar echipa Squid a încercat să clarifice rapid situația.
Modulul vulnerabil nu fusese scris de ei și nu purta nicio amprentă a echipei. Apăruse pe blockchain ca produs al unei terțe părți care alesese să folosească numele Squid pentru a-și boteza propria creație.
Anatomia unui atac care a durat două ore
Firmele de securitate blockchain Blockaid și PeckShield au identificat și raportat incidentul în timp real, oferind o cronologie clară a evenimentelor. Modulul vulnerabil era deja activ pe Ethereum și Base, integrat ca modul de încredere în 86 de portofele Safe diferite. Atacatorul a început să exploateze vulnerabilitatea metodic, țintind fiecare portofel care permisese accesul respectivului contract.
În câteva ore, fondurile au fost scoase, schimbate și consolidate. Conturile compromise aparțineau unor entități variate, printre care utilizatori individuali sofisticați și echipe care administrau active comune. Toate aceste portofele aveau un singur lucru în comun. Aprobaseră modulul SquidRouterModule ca modul de încredere în configurația lor Safe.
Decizia părea inofensivă în momentul aprobării. S-a dovedit însă a fi punctul slab al întregii structuri. În arhitectura Gnosis Safe, un modul de încredere primește autoritate considerabilă asupra portofelului.
Poate executa tranzacții fără a mai cere semnături suplimentare de la proprietarii multisig. Caracteristica asta face Safe extrem de flexibil și permite automatizări utile, dar transformă fiecare modul aprobat într-un potențial vector de atac.
Atacatorul a mizat exact pe acest mecanism. Modulul SquidRouterModule fusese deja autorizat cu drepturi de execuție directă, iar restul a depins doar de viteza cu care putea fi parcursă lista de victime. Cele două ore au fost suficiente pentru golirea sistematică a celor 86 de Safe-uri, fără ca proprietarii lor să poată reacționa în timp util.
Reacția echipei Squid și mesajul transmis comunității
Co-fondatorul pseudonim Fig a luat poziție publică pe X în orele de după atac, cu o formulare neobișnuit de tranșantă. Contractul denumit SquidRouterModule nu are nicio legătură cu protocolul Squid, iar echipa nu știe încă cine a scris sau a publicat acel cod. Tonul a surprins prin directețea lui pentru un anunț corporativ în domeniul cripto, unde precauția juridică tinde de obicei să dilueze mesajele.
Pagina oficială a proiectului a venit cu o explicație suplimentară. Router-ul lor principal este separat arhitectural de modulul compromis și nu a fost atins în niciun fel. Squid a punctat și că relatările timpurii care făceau referire la „SquidRouter” erau tehnic inexacte. Contractul împărtășește numele Squid, dar este produsul unei terțe părți care a ales să se integreze cu Squid, alături de alte protocoale, fără a avea vreun contact direct cu echipa.
Genul ăsta de delimitare este rar întâlnit în industria blockchain, unde brandurile și componentele se împrumută adesea într-un mod neformalizat. Cazul Squid 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, în realitate, nimeni din echipa originală nu a autorizat-o vreodată.
Mesajul către utilizatori a fost limpede. Contractele de bază, integrările oficiale și aprobările active în cadrul protocolului Squid au rămas neatinse. Niciun utilizator care interacționa cu Squid prin canalele oficiale nu a pierdut bani, iar protocolul a continuat să funcționeze normal pe toată durata atacului.
Cum funcționa de fapt vulnerabilitatea?
Detaliile tehnice ale atacului oferă o lecție de manual despre cum nu trebuie scris un contract inteligent. Conform analizei publicate de Squid, modulul vulnerabil accepta un șir constant furnizat de apelant drept dovadă că un mesaj era securizat.
Cu alte cuvinte, oricine cunoștea acest șir putea convinge modulul 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. Consecința e una directă. Mecanismul de protecție al modulului era echivalent cu o ușă încuiată, doar că autorul codului lăsase cheia atârnată într-un cui chiar pe ușa respectivă.
Atacatorul a folosit instrumente bazate pe Foundry, un framework de dezvoltare Ethereum popular printre programatorii cu experiență, pentru a publica contracte de exploit. Aceste contracte apelau funcția DelegateBundler a modulului și se impersonau drept delegați autorizați. Practic, modulul vedea apelurile ca venind din partea unor utilizatori cu drepturi de execuție, deși în realitate veneau de la un atacator complet străin sistemului.
Analiza separată făcută de Blockaid arată că vulnerabilitatea se afla în funcția executeSameChainActions(). Funcția aceasta permitea execuția neautorizată în interiorul conturilor Safe. Combinația dintre validarea greșită și autoritatea acordată modulului crea o gaură de securitate masivă, suficientă cât să dreneze 86 de Safe-uri în mai puțin de două ore.
O eroare elementară cu efecte disproporționate
Ceea ce face cazul remarcabil este simplitatea greșelii fundamentale. Validarea bazată pe un șir constant public este unul dintre cele mai elementare antipattern-uri din scrierea de contracte inteligente.
Programatorii cu experiență în Solidity recunosc imediat tipul ăsta de eroare. Și totuși, modulul a fost publicat în producție, a fost adoptat de zeci de utilizatori sofisticați și a rămas activ suficient timp cât atacatorul să descopere problema și să o exploateze sistematic.
Detaliul ăsta 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. În cazul unui modul cu acces direct la fondurile portofelelor multisig, neglijența este aproape de neconceput. Și totuși s-a întâmplat, iar consecințele sunt vizibile pentru oricine se uită pe Basescan.
Traseul fondurilor furate
Atacatorul a urmat un tipar deja familiar în lumea exploiturilor DeFi. Activele scoase din portofele, printre care USDC, USDT și ENA, au fost dirijate prin pool-uri Uniswap V3 controlate chiar de el. În pool-urile acelea așezase deja un token fără valoare creat de el însuși, numit 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 în pool. Manevra îi permite uneori să eludeze filtrele automate care monitorizează adresele cu transferuri directe către exchange-uri sau mixere cunoscute.
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. Suma a ajuns într-un portofel cu adresa începând cu 0xa447 și terminând în 54859. 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 portofelului atacatorului a venit din Tornado Cash sub forma a 2,1 ETH, un detaliu care nu surprinde pe nimeni din ecosistem. Tornado Cash, mixerul sancționat de autoritățile americane, rămâne instrumentul preferat al actorilor care vor să obscurizeze originea fondurilor înainte de a ataca. Pregătirea făcută prin acest mixer indică un nivel de premeditare considerabil, nu o reacție impulsivă.
Modulele Safe și problema arhitecturală mai largă
Pentru a înțelege de ce tipul ăsta de atac este posibil, e util să privim modul în care funcționează portofelele Safe. Spre deosebire de un portofel obișnuit, unde fiecare tranzacție necesită o semnătură directă, Safe este un portofel multi-semnătură care permite mai multor utilizatori să controleze fondurile împreună. Sistemul a fost gândit pentru echipe, fonduri de investiții și organizații DAO, scenarii în care semnăturile multiple oferă siguranță.
Pe lângă semnăturile clasice, Safe 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 aceasta este folosită pentru automatizări, recurențe, integrări cu alte protocoale și pentru construirea de fluxuri DeFi complexe. E o opțiune puternică, dar tocmai aici se află și riscul.
Când un proprietar Safe 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. Asta s-a întâmplat cu cele 86 de portofele care folosiseră SquidRouterModule.
Industria a discutat ani buni acest risc, dar lecția pare să se repete cu fiecare exploit. Compunabilitatea, capacitatea de a combina protocoale și componente într-un mod asemănător pieselor Lego, este unul dintre punctele forte ale DeFi. Aceeași compunabilitate creează însă suprafețe de atac neașteptate. Securitatea sistemului devine egală cu securitatea celui mai slab modul integrat. În cazul de față, cel mai slab modul s-a dovedit fatal.
O analogie cu lumea aplicațiilor mobile
O paralelă utilă pentru cei neobișnuiți cu termenii blockchain este lumea aplicațiilor mobile cu permisiuni. Când un utilizator instalează o aplicație pe telefonul său și îi acordă acces la contacte, fotografii sau locație, el îi deleagă acelei aplicații o parte din controlul asupra propriilor date. Dacă aplicația e de încredere, totul merge bine. Dacă aplicația ascunde un cod malițios, datele utilizatorului pot fi extrase fără ca el să mai facă ceva.
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 este scris greșit sau cu intenții malițioase, fondurile pleacă undeva și foarte rar mai pot fi recuperate.
Contextul DeFi din 2026
Incidentul SquidRouterModule se adaugă unui an deja dificil pentru securitatea DeFi. Datele agregate publicate de The Block arată că până în acest punct al anului 2026 pierderile cumulate au depășit 770 de milioane de dolari. Doar luna aprilie a stabilit un record nedorit, cu aproximativ 30 de incidente și pierderi care au depășit 630 de milioane de dolari într-un singur interval.
Tiparul de creștere a pierderilor pune presiune nouă pe protocoalele DeFi și pe utilizatorii lor. Pe măsură ce ecosistemul atrage capital instituțional și o adopție mai largă, atacatorii devin mai sofisticați, iar țintele mai valoroase. Modulele de la terți, podurile cross-chain și agregatorii de lichiditate au fost constant printre cele mai vulnerabile componente, tocmai pentru că ele agregă fonduri din mai multe surse și interacționează cu mai multe contracte.
Coincidența ironică în cazul Squid este că protocolul 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 pentru a-și apăra brandul î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 are nicio responsabilitate.
Lecția mai puțin spectaculoasă despre permisiuni
Atacul are o latură instructivă dincolo de partea pur tehnică. Niciun cod al protocolului Squid nu a fost compromis. Niciun utilizator al Squid nu a pierdut bani folosind protocolul ca atare. Ș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ă un audit profund al acestuia.
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.
Recomandarea practică pe care experții o repetă după fiecare astfel de incident sună simplu, dar este greu de aplicat în practică. Utilizatorii ar trebui să își revizuiască periodic permisiunile acordate, să revoce accesul modulelor care nu mai sunt active și să trateze fiecare nouă aprobare ca pe o cheie suplimentară către portofel. Majoritatea oamenilor nu fac acest exercițiu regulat, iar ecosistemul DeFi nu oferă încă unelte suficient de simple pentru gestiunea acestor permisiuni la nivel mainstream.
Întrebări deschise care urmează investigația
Cea mai stranie parte a poveștii rămâne identitatea celui care a publicat SquidRouterModule. Squid spune deschis că nu știe cine a scris contractul sau cine l-a pus pe blockchain. Necunoașterea aceasta este, în sine, o problemă. Un contract poate purta numele unui protocol cunoscut, poate fi verificat pe exploratorul blockchain și poate atrage 86 de portofele Safe ca utilizatori, fără ca echipa originală să afle vreodată de existența sa. Asta arată o gaură instituțională în felul în care ecosistemul își gestionează brandurile.
Investigațiile probabil vor încerca să determine dacă cel care a publicat modulul este același cu atacatorul, dacă au existat colaboratori și dacă cei 3,07 milioane de DAI vor fi mișcați în continuare. Istoria recentă a exploiturilor DeFi sugerează că o parte din fonduri va fi probabil mutată prin Tornado Cash și alte mixere, în vreme ce o altă parte ar putea rămâne în portofelul de consolidare perioade lungi, dacă atacatorul consideră că presiunea publică este prea mare pentru o mișcare imediată.
Squid nu a anunțat planuri pentru un program de rambursare a utilizatorilor afectați, ceea ce este consistent cu poziția lor că protocolul nu este responsabil pentru exploit. Decizia este logică din punct de vedere juridic și financiar, dar pune utilizatorii păgubiți într-o situație dificilă. Ei trebuie să caute alte căi pentru recuperarea fondurilor, fie prin investigații independente, fie prin urmărirea atacatorului pe lanț, cu speranța că acesta va comite eroarea de a interacționa cu un exchange centralizat care implementează KYC.
O lecție despre încrederea în nume
Cazul SquidRouterModule rămâne, până la urmă, o lecție despre cât de puțin contează un nume pe blockchain atunci când vine vorba de securitate. Două contracte pot avea nume identice sau 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.
Distincția aceasta este fundamentală pentru utilizatorii care interacționează cu DeFi la un nivel avansat. 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.
Anunțurile oficiale, documentația publicată, link-urile direct de pe site-ul protocolului, toate acestea sunt straturi suplimentare de validare care lipsesc atunci când un utilizator descoperă un contract pe un explorator și presupune că este oficial doar pentru că poartă un nume cunoscut.
În ecosistemul de astăzi al rețelelor multiple și al protocoalelor compozabile, disciplina aceasta devine din ce în ce mai grea de menținut. Numărul de contracte cu care interacționează un utilizator mediu DeFi a crescut exponențial. Numărul de aprobări active într-un portofel obișnuit poate ajunge la zeci sau sute.
Pe acest fond, atacatorul nu trebuie să spargă criptografia, nu trebuie să găsească un bug în Solidity al unui protocol mare, nu trebuie să atace direct un brand cu reputație. Trebuie doar să găsească un singur modul prost scris, adoptat de portofele cu fonduri, și să exploateze acea vulnerabilitate.
Numele care nu aparținea nimănui
Industria criptomonedelor a avut multe momente de reflexie în ultimii ani, dar lecția modulelor Safe pare să fie una pe care comunitatea o învață în mod repetat. Auditurile de securitate riguroase pentru fiecare modul integrat ar trebui să fie standardul, însă în practică multe componente terțe ajung să fie folosite fără o evaluare profundă, mai ales când vin cu numele unui protocol cunoscut atașat de funcționalitatea lor.
Squid a comunicat că vor urma mai multe informații pe măsură ce investigația avansează. Atenția va rămâne pe înțelegerea exactă a modului în care a funcționat exploitul și pe închiderea integrărilor de la terți într-un mod mai strict. Niciun calendar nu a fost anunțat, iar acțiunile specifice nu au fost încă detaliate, ceea ce lasă comunitatea într-un stadiu de așteptare.
Pentru utilizatorii care au pierdut bani, perspectiva este probabil reconfortantă doar într-un mod limitat. Cei 3,2 milioane de dolari rămân în portofelul atacatorului, sub formă de DAI gata să fie mutată în orice clipă.
Protocolul de bază al Squid continuă să funcționeze, neatins de eveniment. Iar undeva pe blockchain, un nume care nu aparținea nimănui în mod oficial a generat o vulnerabilitate care arată cât de fragilă este granița dintre brand și cod în DeFi-ul de astăzi.
Intrebari Frecvente(FAQ)
Este un atac desfășurat pe 25 mai 2026 asupra unui modul Safe publicat pe Ethereum și Base sub numele SquidRouterModule. Atacatorul a sustras aproximativ 3,2 milioane de dolari din 86 de portofele Gnosis Safe în mai puțin de două ore, exploatând o vulnerabilitate de validare în codul modulului.
Nu. Squid a clarificat public că modulul vulnerabil nu a fost dezvoltat, publicat sau operat de echipa sa. Router-ul principal al protocolului este separat arhitectural și nu a fost compromis. Utilizatorii care interacționează cu Squid prin canalele oficiale nu au pierdut bani.
Modulul accepta un șir constant public ca dovadă de securitate pentru tranzacții. Cunoscând acest șir, atacatorul putea executa calldata arbitrară pe portofelele care îi acordaseră încredere, fără a fi nevoie de semnături. Vulnerabilitatea se afla în funcția executeSameChainActions(), iar atacul s-a derulat prin DelegateBundler, cu contracte de exploit construite în Foundry.
Activele furate, printre care USDC, USDT și ENA, au fost schimbate prin pool-uri Uniswap V3 controlate de atacator pe un token fără valoare numit „u”. Atacatorul a retras apoi lichiditatea, păstrând activele reale, și a consolidat 3,07 milioane DAI într-un portofel cu adresa începând cu 0xa447.
Squid nu a anunțat un program de rambursare. Protocolul nu se consideră responsabil pentru exploit, deoarece modulul atacat era produsul unei terțe părți, nu o componentă oficială Squid. Utilizatorii păgubiți trebuie să caute alte căi de recuperare a fondurilor.
Gnosis Safe (cunoscut acum sub numele Safe) este un portofel multi-semnătură folosit pe scară largă în DeFi pentru echipe, fonduri și DAO-uri. Permite delegarea unor permisiuni către contracte externe numite „module”. Caracteristica este flexibilă, dar poate deveni vector de atac dacă modulul aprobat conține vulnerabilități.
Identitatea autorului nu este cunoscută public. Squid a declarat deschis că nu știe cine a scris sau publicat modulul, în ciuda faptului că acesta poartă numele protocolului. Investigațiile în curs ar putea determina dacă autorul codului este aceeași persoană cu atacatorul sau o entitate separată.
Securitatea unui portofel Safe depinde și de modulele aprobate. Aprobarea unui modul terț acordă acces direct la fonduri, iar dacă acel cod este vulnerabil sau scris cu intenții malițioase, portofelul poate fi golit fără o spargere a cheilor private. Revocarea permisiunilor neutilizate și auditarea independentă a modulelor înainte de aprobare rămân măsuri esențiale.
