Firmy zajmujące się bezpieczeństwem blockchainów — Blockaid, PeckShield oraz BlockSec — potwierdziły exploit, który opróżnił portfel Gnosis Safe na Ethereum z rsETH o wartości około 7,8 mln USD — około 2900 tokenów. Safe to portfel oparty na kontraktach inteligentnych, szeroko używany do zabezpieczania dużych zasobów on-chain, a rsETH to token płynnego restakingu emitowany przez KelpDAO — zbywalna reprezentacja aktywów poddanych restakingowi. Według raportów tych firm incydent rozpoczął się 15 września o godz. 04:38 UTC transakcją, która przeniosła większość środków, a w ciągu następnej godziny nastąpiło kilka mniejszych transakcji o łącznej wartości dodatkowych ok. 160 000 USD.

Wadliwe sprawdzenie autoryzacji umożliwiło dowolne wykonanie kodu

Przyczyną źródłową był wadliwy sprawdzian autoryzacji w koncie executora, zidentyfikowanym przez analityków jako adres 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Ukierunkowany Safe, należący do dużego posiadacza rsETH z dźwignią, opierał się na module executora strategii z białej listy, który udostępniał tzw. recipe entrypoint. Ten entrypoint przekazywał w całości calldata dostarczone przez wywołującego do funkcji execTransactionFromModuleReturnData portfela Safe z użyciem operation=1 (DELEGATECALL) — operacji pozwalającej wywołanemu kodowi działać w kontekście wywołującego — bez ograniczania zewnętrznych wywołujących. Ustawienie przekazanego parametru kontraktu na adres samego executora przechodziło walidację, co oznaczało, że każdy, kto mógł dotrzeć do entrypointa, mógł wykonać dowolny kod wewnątrz Safe, skutecznie uzyskując pełną kontrolę nad jego aktywami.

Atakujący użył publicznego keeper multicall, aby skierować autoryzowany moduł Uni V4 LP Safe do utworzonej przez siebie puli Uniswap V4 z hookiem, wykonując operacje poprzez Permit2 i PositionManager. W ramach przygotowań atakujący wdrożył bezwartościowy token nazwany „Permissionless Attacker Token” (PAT) i dostarczył około 2900 aEthrsETH jako płynność przeciwko niemu. Niestandardowy hook w puli rozpakował następnie aEthrsETH do rsETH i przepompował go poza Safe, który pozostał z bezwartościowym LP NFT.

Blockaid exploit detection system detected an exploit on an unidentified user's Safe on Ethereum. ~$7.73M confirmed rsETH loss so far. An attacker used a public keeper multicall to drive a custom Uni V4 LP Safe module into an attacker-created hooked pool; the hook unwrapped…

— Blockaid (@blockaid_) 15 września 2026

Bot MEV wyprzedził atak; KelpDAO nakłada tymczasową pauzę

Co istotne, oryginalna transakcja ataku nigdy nie dotarła do zamierzonego beneficjenta. Atakujący uruchomił exploit bezpośrednio w publicznym mempool, gdzie został wyprzedzony przez bota MEV o nazwie „yoink”, który przejął całe ok. 2882 rsETH — o wartości około 7,8 mln USD — i przekierował je na adres 0xC70f00CD7E461686b04B0E912E309becA8b80ea0. W efekcie to bot maksymalizacji wartości wyodrębnialnej — program wykorzystujący kolejność transakcji w bloku — a atakujący, zakończył sprawę z ukradzionymi środkami.

W odpowiedzi KelpDAO ogłosił, że wykrył podejrzaną aktywność na adresie odbiorczym i nałożył na niego prewencyjną 24-godzinną pauzę, podczas której rsETH nie może być przesyłany ani z niego wyprowadzany. Zespół oświadczył, że współpracuje z ekspertami ds. bezpieczeństwa nad dochodzeniem i podkreślił, że środek dotyczy wyłącznie poziomu portfela: kontrakty Kelp pozostają bezpieczne, rsETH jest w pełni zabezpieczony, a wszystkie operacje emisji, wypłat i integracji przebiegają normalnie, bez konieczności jakichkolwiek działań ze strony użytkowników.

We've detected potential suspicious activity on an the address (0xc70f00cd7e461686b04b0e912e309becA8b80ea0) that received rsETH a few hours ago. Out of an abundance of caution, we've placed that address under a temporary 24-hour pause. During this window, rsETH cannot move in…

— Kelp (@KelpDAO) 15 września 2026

Nadużycie na poziomie modułu, a nie podatność w rdzeniu Safe

Analitycy ds. bezpieczeństwa podkreślali, że było to nadużycie autoryzacji modułu dotyczące jednego Safe, a nie podatność w kontraktach rdzenia Safe ani w kluczach właścicieli. Ponieważ moduły Safe wykonują się z uprawnieniami samego portfela, wada nawet zaufanego rozszerzenia z białej listy może narazić cały stan konta bez jakiegokolwiek naruszenia kontroli właściciela. Incydent ten niemniej uwypukla utrzymujące się ryzyko dla użytkowników portfeli opartych na kontraktach inteligentnych: rdzeń Safe nigdy nie doświadczył bezpośredniego exploita protokołu, jednak użytkownicy wielokrotnie tracili środki poprzez skompromitowaną infrastrukturę i podatne rozszerzenia podmiotów trzecich, w tym ponad 2 mln USD ukradzione w atakach address-poisoning, które dotknęły 21 użytkowników Safe w 2023 roku.

Źródło: Metaverse Post