Jak 18 pakietów dostało backdoora
O 20:24 UTC 8 lipca 2026 portfel, który wczytał najnowszą kompilację @injectivelabs/sdk-ts, po cichu przekazał swoją frazę seed atakującemu. Pierwszy złośliwy commit dopiero co trafił do repozytorium i pozostał aktywny przez około 49 minut, zanim ktokolwiek to zauważył.
Atakujący nie włamali się siłą. Wykorzystali konto GitHub zaufanego współtwórcy działającego od dawna, aby wypchnąć trzy commity, które umieściły backdoora w SDK w wersji 1.20.21, oraz w 17 zależnych pakietach przypiętych dokładnie do tej wersji. Łącznie tę samą truciznę niosło osiemnaście pakietów. Backdoor przechwytywał PrivateKey.fromMnemonic() i PrivateKey.fromHex(), więc wykradał frazy seed BIP-39 oraz klucze prywatne w chwili, gdy portfel się inicjował.
Zanim opiekun to wychwycił, wycofał zmiany i wydał czystą wersję 1.20.23, doszło do około 310 pobrań. Injective Labs twierdzi, że nie utracono żadnych środków użytkowników. Złośliwą wersję oznaczono w npm jako przestarzałą, zamiast ją usunąć, więc nadal figuruje w rejestrze jako znak ostrzegawczy.
Zaufany potok był słabym punktem
Zabezpieczeniem miał być sam mechanizm dostarczania. Złośliwa wersja przeszła przez własny zaufany potok wydawniczy Injective Labs w npm, ścieżkę OIDC zbudowaną właśnie po to, aby usunąć ryzyko skradzionego tokenu publikacji.
To jest ta niewygodna część. Zaufana publikacja OIDC oznacza, że pakiet można wydać bez żadnego długotrwałego tokenu npm, który dałoby się ukraść, co jest realnym zyskiem dla bezpieczeństwa. Ale oznacza też, że przejęte konto człowieka w połączeniu z automatyczną kompilacją zamienia to zaufanie w ścieżkę ataku. Nie było tokenu, który mógłby wyciec, bo podpisu dokonywał sam potok, a potok ufał kontu, które według GitHuba było wiarygodne.
Co sprawdzić we własnych zależnościach
Wniosek jest tu ogólny, nie dotyczy wyłącznie kryptowalut. Każdy, kto wydaje oprogramowanie, dziedziczy dokładnie tę samą ekspozycję przez zależności przechodnie, czyli pakiety, od których zależą twoje pakiety i których nigdy nie wybrałeś do bezpośredniej instalacji.
Przypnij zależności przechodnie do znanych, sprawdzonych wersji i skanuj je, aby podmiana w trakcie, przy przypiętej wersji, ujawniła się jako zmiana, zamiast prześlizgnąć się niezauważona. Traktuj automatyzację zaufanego wydawcy jako ograniczenie jednego ryzyka, a nie usunięcie wszystkich, bo droga przez przejęte konto człowieka pozostaje otwarta. Rotuj też każdy sekret, klucz i poświadczenie, które przeszło przez kompilację budzącą teraz twoje podejrzenia, zakładając, że zostało już zobaczone.
Czytaj dalej: Progress: klienci ShareFile mają wyłączyć serwer | Luka w Defenderze daje użytkownikowi pełną kontrolę



