
Wprowadzenie do problemu / definicja
KelpDAO, projekt DeFi wykorzystujący model liquid restakingu w ekosystemie Ethereum, padł ofiarą poważnego incydentu bezpieczeństwa związanego z obsługą tokena rsETH. W wyniku ataku doszło do nieautoryzowanego przemieszczenia około 116,5 tys. rsETH, których wartość oszacowano na blisko 290 mln USD.
Wstępne ustalenia wskazują, iż za operacją może stać zaawansowany aktor powiązany z północnokoreańską grupą Lazarus. To kolejny przypadek pokazujący, iż współczesne zagrożenia dla sektora DeFi obejmują nie tylko smart kontrakty, ale również całą infrastrukturę wspierającą mechanizmy walidacji i komunikacji między łańcuchami.
W skrócie
- Atak dotknął mechanizmu walidacji komunikatów cross-chain wykorzystywanego przez rsETH.
- Napastnicy mieli przejąć część węzłów RPC i równocześnie zakłócić działanie poprawnych źródeł danych.
- System zaakceptował fałszywy komunikat międzyłańcuchowy jako prawidłowy.
- Umożliwiło to transfer aktywów bez rzeczywistego odpowiednika on-chain.
- Po incydencie ograniczono część operacji związanych z rsETH, a niektóre protokoły DeFi zmniejszyły jego użycie jako zabezpieczenia.
Kontekst / historia
Liquid restaking to model, w którym użytkownik deponuje aktywa, a w zamian otrzymuje płynny token reprezentujący pozycję stakingową lub restakingową. W przypadku KelpDAO takim aktywem jest rsETH, który może być następnie używany w innych aplikacjach DeFi, także w scenariuszach obejmujących wiele łańcuchów.
Tego rodzaju architektura zwiększa efektywność kapitału, ale jednocześnie rozszerza powierzchnię ataku. Ryzyko nie ogranicza się tu do pojedynczego kontraktu, ale obejmuje mosty, systemy walidacji wiadomości, komponenty infrastrukturalne oraz poprawność danych przekazywanych pomiędzy środowiskami blockchain.
Podejrzaną aktywność wykryto 18 kwietnia 2026 r., po czym uruchomiono działania mające ograniczyć skutki incydentu. Zdarzenie gwałtownie przyciągnęło uwagę rynku, ponieważ schemat operacyjny wpisuje się w znane działania grup wyspecjalizowanych w kradzieży aktywów cyfrowych na dużą skalę.
Analiza techniczna
Kluczowym elementem incydentu była warstwa walidacji komunikatów cross-chain, określana jako DVN. Odpowiada ona za potwierdzenie, czy zdarzenie zaobserwowane w jednym łańcuchu powinno zostać uznane za wiążące w innym środowisku. o ile ten etap zostanie skompromitowany, logika aplikacji może wykonać operacje na podstawie fałszywych danych.
Z dostępnych informacji wynika, iż atak miał charakter wieloetapowy. Napastnicy mieli przejąć kontrolę nad wybranymi węzłami RPC wykorzystywanymi przez mechanizm weryfikacyjny, a jednocześnie ograniczyć dostępność zdrowych węzłów przy użyciu zakłóceń przypominających DDoS. Taki model ataku zwiększa szansę, iż system oprze decyzję na zatrutych źródłach danych.
W efekcie zaakceptowano fałszywy komunikat międzyłańcuchowy, mimo iż odpowiadająca mu transakcja nie została faktycznie wykonana w łańcuchu źródłowym. To umożliwiło nieautoryzowany transfer rsETH. Technicznie nie był to więc klasyczny exploit pojedynczej luki w smart kontrakcie, ale kompromitacja procesu zaufania do danych wejściowych dostarczanych warstwie walidacyjnej.
Po przejęciu środków aktywa miały zostać gwałtownie rozproszone i przemieszczone z użyciem narzędzi utrudniających analizę przepływów, w tym usług anonimizujących. Taki etap post-exploitation odpowiada wzorcom działań zaawansowanych grup ukierunkowanych na sektor kryptowalutowy.
Konsekwencje / ryzyko
Skutki incydentu wykraczają poza samą stratę finansową. Atak pokazuje, iż bezpieczeństwo protokołów DeFi zależy również od odporności warstw pośrednich, takich jak węzły RPC, systemy walidacji wiadomości, relayerzy i inne komponenty poza samym łańcuchem bloków.
Dla użytkowników oznacza to ryzyko spadku zaufania do rsETH, ograniczenia płynności oraz czasowego wstrzymania części funkcji protokołu. Dla zintegrowanych platform pożyczkowych i innych aplikacji DeFi może to z kolei oznaczać konieczność rewizji parametrów ryzyka, zmian w akceptacji zabezpieczeń oraz wdrożenia mechanizmów awaryjnych.
W szerszej perspektywie incydent potwierdza, iż grupy sponsorowane przez państwa rozwijają kompetencje w zakresie ataków na złożone systemy finansów zdecentralizowanych. Zamiast szukać wyłącznie pojedynczych błędów w kodzie, coraz częściej uderzają w infrastrukturę pomocniczą i procesy decydujące o tym, jakie dane system uzna za wiarygodne.
Rekomendacje
Organizacje rozwijające rozwiązania DeFi i integracje cross-chain powinny potraktować ten incydent jako ostrzeżenie przed nadmiernym zaufaniem do warstw pośrednich. Ochrona powinna obejmować nie tylko kod kontraktów, ale także architekturę źródeł danych, procedury awaryjne i monitoring integralności procesu walidacji.
- Dywersyfikować dostawców RPC i rozdzielać ich między niezależne domeny administracyjne.
- Wdrażać quorum oraz dodatkowe kontrole spójności danych wejściowych.
- Oddzielać mechanizmy dostępności od mechanizmów poprawności, aby awaria lub DDoS nie wymuszały automatycznego zaufania do słabszych źródeł.
- Stosować limity transferów, opóźnienia dla operacji wysokiej wartości oraz mechanizmy circuit breaker.
- Monitorować korelację między zdarzeniami on-chain a telemetrią infrastrukturalną.
- Regularnie ćwiczyć scenariusze incident response obejmujące kompromitację walidacji i utratę zaufania do dostawcy RPC.
- Analizować ekspozycję zależnych protokołów, zwłaszcza tam, gdzie tokeny pochodne są używane jako zabezpieczenie.
Warto również rozwijać threat intelligence ukierunkowany na grupy APT atakujące branżę kryptowalutową, aby szybciej identyfikować wzorce działań, infrastrukturę operacyjną i techniki maskowania przepływu środków.
Podsumowanie
Atak na KelpDAO należy do najpoważniejszych incydentów DeFi w 2026 roku i pokazuje, jak groźne mogą być słabości w warstwach walidacji komunikatów cross-chain. Problem nie dotyczy wyłącznie jednego protokołu, ale całej klasy rozwiązań opartych na zaufaniu do zewnętrznych komponentów infrastrukturalnych.
Najważniejszy wniosek dla branży jest jasny: bezpieczeństwo architektur wielołańcuchowych musi obejmować pełny łańcuch zaufania, od smart kontraktów po węzły RPC, mechanizmy walidacyjne i procedury operacyjne. Bez tego choćby poprawny kod on-chain może nie wystarczyć, by ochronić aktywa użytkowników.






