Co znajdziesz w tym artykule?
Wprowadzenie do problemu
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najgroźniejszych zagrożeń dla ekosystemu open source. W opisanym incydencie doszło do kompromitacji procesu publikacji pakietów powiązanych z Injective Labs, czego skutkiem było umieszczenie w rejestrze npm złośliwej wersji biblioteki SDK przeznaczonej do obsługi funkcji kryptograficznych.
Najważniejszym celem ataku była kradzież materiału umożliwiającego odtworzenie portfeli kryptowalutowych, w tym kluczy prywatnych oraz fraz mnemonic seed. To sprawia, że incydent należy oceniać nie tylko jako problem deweloperski, ale również jako bezpośrednie zagrożenie finansowe dla użytkowników i organizacji korzystających z podatnych zależności.
W skrócie
- Zainfekowana została wersja
@injectivelabs/sdk-ts@1.20.21. - Złośliwy kod przechwytywał dane służące do generowania kluczy prywatnych.
- Problem objął również pakiety zależne w przestrzeni
@injectivelabs. - Aktywacja malware następowała podczas użycia biblioteki, a nie w czasie instalacji.
- Zalecane działania obejmują aktualizację, analizę zależności i natychmiastową rotację sekretów.
Kontekst i historia incydentu
Według ujawnionych informacji skażona wersja pakietu została opublikowana 8 lipca 2026 roku. Napastnicy wykorzystali zaufany kanał publikacji związany z oficjalnym repozytorium projektu, dzięki czemu złośliwy artefakt wyglądał jak legalna aktualizacja pochodząca z wiarygodnego źródła.
Skala ryzyka wzrosła dodatkowo dlatego, że zainfekowany pakiet został powiązany z wieloma innymi zależnościami w ekosystemie Injective Labs. W praktyce oznacza to klasyczny scenariusz kompromitacji upstreamu, w którym atakujący przejmuje zaufany element procesu wytwórczego, a następnie dystrybuuje szkodliwy kod do środowisk deweloperskich, pipeline’ów CI/CD i aplikacji produkcyjnych.
Analiza techniczna
Technicznie incydent wyróżnia się tym, że złośliwa logika nie była uruchamiana przez typowe skrypty lifecycle na etapie instalacji pakietu. Zamiast tego aktywacja następowała dopiero wtedy, gdy aplikacja korzystała z funkcji biblioteki odpowiedzialnych za operacje kryptograficzne. Taki model działania utrudniał wykrycie przez standardowe mechanizmy kontroli bezpieczeństwa.
Zmodyfikowany kod ingerował w legalne funkcje związane z generowaniem materiału kryptograficznego. Dodane fragmenty przedstawiano jako element telemetryczny, jednak ich rzeczywistym zadaniem było przechwytywanie danych wejściowych używanych do wyprowadzania kluczy, w tym fraz mnemonic oraz innych informacji pozwalających odtworzyć tożsamość kryptograficzną użytkownika.
Mechanizm eksfiltracji został zaprojektowany w sposób prosty, ale skuteczny. Zamiast wysyłać każde zdarzenie osobno, malware kolejkował dane i przesyłał je zbiorczo pojedynczym żądaniem HTTPS POST do zewnętrznej infrastruktury. Ograniczało to liczbę podejrzanych połączeń wychodzących i zmniejszało szansę wykrycia przez monitoring sieciowy.
Szczególnie alarmujący jest również aspekt tożsamości użytej do wprowadzenia zmian. Ustalenia wskazują, że złośliwe commity pochodziły z konta dewelopera z historią wcześniejszych kontrybucji, co sugeruje wykorzystanie zaufania do istniejącego maintainera oraz legalnych mechanizmów publikacji opartych na trusted publisher i OIDC.
Konsekwencje i ryzyko
Ryzyko związane z tym incydentem należy uznać za krytyczne dla wszystkich środowisk, w których przy użyciu podatnej biblioteki przetwarzano frazy seed, klucze prywatne albo dane służące do ich generowania. W takim scenariuszu atakujący mógł uzyskać pełną możliwość odtworzenia portfela i przejęcia środków.
Zagrożenie nie dotyczy wyłącznie zespołów, które świadomie instalowały pakiet @injectivelabs/sdk-ts. Z uwagi na zależności pośrednie narażone mogły być również projekty pobierające skażony komponent tranzytywnie. To istotnie utrudnia ocenę ekspozycji, zwłaszcza w dużych środowiskach monorepo, złożonych systemach buildowych i organizacjach korzystających z wewnętrznych mirrorów pakietów.
Dodatkowym problemem pozostaje fakt, że nawet po oznaczeniu wersji jako niebezpiecznej artefakty mogły nadal znajdować się w cache, lockfile’ach oraz archiwalnych pipeline’ach. Z tego powodu analiza musi objąć nie tylko bieżący stan projektu, ale również historię buildów i wcześniejsze wdrożenia.
Rekomendacje
Organizacje korzystające z pakietów Injective Labs powinny w pierwszej kolejności ustalić, czy w ich środowiskach występowała wersja 1.20.21 pakietu @injectivelabs/sdk-ts albo pakiety zależne przypięte do tej wersji. Konieczna jest analiza plików lock, cache menedżerów pakietów oraz logów systemów CI/CD.
Jeżeli złośliwy pakiet był obecny w środowisku deweloperskim, testowym lub produkcyjnym, wszystkie frazy seed, klucze prywatne i dane użyte do ich generowania należy traktować jako skompromitowane. W praktyce oznacza to potrzebę natychmiastowej rotacji sekretów, migracji aktywów do nowych portfeli oraz unieważnienia dotychczasowych poświadczeń kryptograficznych.
- Wymusić pinowanie zaufanych wersji zależności.
- Skanować różnice między kodem źródłowym a publikowanymi artefaktami.
- Monitorować zależności tranzytywne, a nie tylko bezpośrednie.
- Wdrożyć polityki integralności dla instalowanych i publikowanych pakietów.
- Stosować podpisywanie artefaktów, attestation i weryfikację provenance.
- Wzmocnić ochronę kont maintainerów przy użyciu MFA i kluczy sprzętowych.
- Regularnie przeglądać konfigurację trusted publisher oraz federację tożsamości w CI/CD.
- Analizować ruch wychodzący z procesów build i aplikacji wykorzystujących biblioteki kryptograficzne.
W środowiskach podwyższonego ryzyka warto dodatkowo wdrożyć detekcję semantyczną zmian w bibliotekach odpowiedzialnych za key derivation, obsługę fraz seed i zarządzanie portfelami. Każda modyfikacja takich funkcji powinna być traktowana jako zmiana krytyczna wymagająca rozszerzonego przeglądu bezpieczeństwa.
Podsumowanie
Incydent związany z Injective Labs pokazuje, że współczesne ataki na łańcuch dostaw coraz częściej wykorzystują legalne kanały publikacji oraz zaufane tożsamości współtwórców projektów open source. Złośliwa biblioteka nie wyróżniała się agresywnym zachowaniem podczas instalacji, lecz uruchamiała się dopiero w kontekście realnego użycia funkcji kryptograficznych, co zwiększało skuteczność operacji i utrudniało detekcję.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że sama analiza znanych podatności nie wystarcza. Ochrona ekosystemu musi obejmować integralność procesu publikacji, kontrolę zależności pośrednich oraz obserwację zachowania bibliotek w czasie wykonania. W przypadku komponentów przetwarzających klucze prywatne nawet pojedyncza kompromitacja może prowadzić do bezpośrednich strat finansowych i trwałego naruszenia zaufania.