Atak na Injective i nowe luki w DeFi

Hakerzy celują w narzędzia deweloperów i stare kontrakty

Świat krypto mierzy się z kolejną falą ataków, która pokazuje, że zagrożenie nie dotyczy już wyłącznie samych blockchainów czy smart kontraktów. Coraz częściej celem stają się narzędzia deweloperskie, biblioteki i stare, pozornie zapomniane kodbases, które wciąż pozostają aktywne lub nadal są używane przez aplikacje.

Najgłośniejszy z ostatnich incydentów dotyczył ekosystemu Injective. Zainfekowany pakiet npm został użyty do próby kradzieży prywatnych kluczy i seed phrase użytkowników portfeli. Równolegle eksperci ds. bezpieczeństwa alarmują, że sztuczna inteligencja znacząco skraca „okres przydatności” audytów bezpieczeństwa i sprawia, że projekty muszą wracać do analizy kodu częściej niż dotychczas.

Injective: zainfekowany pakiet npm i kradzież kluczy

Według ujawnionych informacji atak dotyczył pakietu @injectivelabs/sdk-ts w ekosystemie npm. Wersja 1.20.21 została zmodyfikowana po przejęciu konta dewelopera na GitHubie. Podejrzane commity zaczęły pojawiać się 8 czerwca 2026 r.

Pakiet miał około 50 tys. pobrań tygodniowo, a zainfekowana wersja została pobrana 310 razy. Problem był poważniejszy niż wyglądał na pierwszy rzut oka, bo szkodliwy kod został podpięty także pod 17 innych pakietów w przestrzeni Injective Labs. To oznacza, że zagrożeni mogli być nie tylko ci, którzy instalowali SDK bezpośrednio.

Malware działał podstępnie: przechwytywał funkcje odpowiedzialne za generowanie kluczy portfela, zapisywał private keys i mnemonics, a następnie wysyłał je na zewnętrzny adres udający legalny serwer sieci Injective. Innymi słowy, aplikacja deweloperska mogła nieświadomie przekazać atakującym dane potrzebne do przejęcia portfeli.

Zespół bezpieczeństwa zwrócił uwagę, że każde klucze lub seed phrase przetworzone przez zainfekowane pakiety należy traktować jako skompromitowane. Deweloper odpowiedzialny za przejęte konto miał szybko wykryć incydent, jednak kampania nie była jeszcze w pełni opanowana w momencie publikacji informacji.

Władze projektu przekazały, że problem został już naprawiony, a objęte nim wersje pakietów zostały zdeprecjonowane. Jednocześnie podkreślono, że fundusze w sieci nie były zagrożone, choć nie wskazano, czy jakiekolwiek środki faktycznie zostały skradzione.

Supply chain attack staje się coraz groźniejszy

Ten przypadek wpisuje się w rosnący trend tzw. supply chain attacks, czyli ataków na łańcuch dostaw oprogramowania. Zamiast atakować sam blockchain, przestępcy przejmują zaufane narzędzia używane przez deweloperów do budowy portfeli, giełd i aplikacji.

To szczególnie niebezpieczne, ponieważ jeden kompromis może posłużyć do dystrybucji złośliwego kodu do wielu kolejnych projektów. Tego typu działania wykorzystują zaufanie do popularnych platform, takich jak GitHub czy npm.

AI skraca czas życia audytów bezpieczeństwa

Drugim istotnym wnioskiem z najnowszych analiz jest to, że jednorazowy audyt smart kontraktu przestaje wystarczać. Specjaliści ds. bezpieczeństwa wskazują, że rozwój narzędzi opartych na AI ułatwia hakerom szybsze wyszukiwanie słabych punktów w kodzie.

W praktyce oznacza to, że projekt może przejść audyt przy starcie, a mimo to po kilku miesiącach lub latach nadal pozostawać podatny na atak, jeśli jego kod nie jest ponownie sprawdzany. Eksperci podkreślają więc potrzebę ciągłego przeglądu kodu, a nie jednorazowej certyfikacji bezpieczeństwa.

Przykład z Zcash

Dobrym przykładem jest przypadek Zcash, gdzie badacz bezpieczeństwa wykrył poważną lukę przy użyciu niestandardowego agenta audytowego opartego na Anthropic’s Claude Opus 4.8. Błąd istniał przez cztery lata i mógł umożliwić niewykrywalne fałszowanie środków w Orchard shielded pool, jednym z kluczowych elementów prywatności tej sieci. Luka została już załatana.

To ważny sygnał dla całej branży: nawet dojrzałe projekty z wieloletnią historią mogą mieć w kodzie błędy, które nie zostały wychwycone podczas wcześniejszych kontroli.

Ataki na stare protokoły też nie znikają

Problem nie kończy się na aktywnych projektach. Hakerzy coraz częściej wracają do starych lub wygaszonych protokołów DeFi, które nadal posiadają podatne smart kontrakty albo zamrożone środki.

W ostatnim czasie odnotowano między innymi:

• atak na Aztec Connect, z którego wyprowadzono 2,1 mln dolarów;
• exploit na smart kontrakcie mySwap, który kosztował około 300 tys. dolarów;
• odzyskanie 1 003 ETH o wartości ponad 1,72 mln dolarów z projektu Hong Coin (HONG) dzięki działaniu white hat-a znanego jako 0xflorent.

Te przypadki pokazują, że nawet projekty zamknięte lub nieaktywne nadal mogą stanowić cel, jeśli ich kontrakty pozostają podatne na błędy.

Rosnące straty i presja na branżę

Według przytoczonych danych w pierwszej połowie 2026 roku ataki na portfele były najbardziej kosztownym wektorem kradzieży, odpowiadając za 444 mln dolarów utraconych w 33 incydentach. Jednocześnie odnotowano, że przestępcy są coraz lepiej przygotowani i korzystają z bardziej zaawansowanych metod niż jeszcze rok wcześniej.

W tle pozostaje też ogromna wartość zamknięta w DeFi. W setkach protokołów znajduje się obecnie ponad 72,3 mld dolarów, co tylko zwiększa motywację do szukania luk w smart kontraktach.

Co to oznacza dla rynku krypto?

Najważniejszy wniosek jest prosty: bezpieczeństwo w krypto nie kończy się na wdrożeniu kodu. Trzeba chronić:

• środowisko deweloperskie,
• zależności i biblioteki,
• konta GitHub i inne narzędzia używane do publikacji paczek,
• stare smart kontrakty, nawet jeśli projekt formalnie już nie działa.

Dzisiejsze ataki pokazują, że zaufany software może stać się bramą dla złośliwego kodu, a audyt przeprowadzony raz na start nie daje już wystarczającej ochrony. W branży, w której miliardy dolarów nadal siedzą w smart kontraktach, taki wniosek ma bardzo praktyczne znaczenie.