Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla zespołów deweloperskich, DevOps i bezpieczeństwa. Najnowszy incydent dotyczy pakietu tensorlake w rejestrze npm, gdzie opublikowano złośliwą wersję zawierającą komponenty służące do kradzieży poświadczeń, utrwalania obecności w środowisku oraz prób dalszego rozprzestrzeniania się. To przykład sytuacji, w której zaufany pakiet open source staje się nośnikiem malware uruchamianego już podczas instalacji zależności.
W skrócie
Złośliwa wersja tensorlake@0.5.144 została opublikowana jako skompromitowane wydanie oficjalnego pakietu TypeScript SDK. Ładunek aktywował się przez skrypt preinstall, co oznacza, że wykonywał się automatycznie podczas instalacji. Malware powiązano z rodziną Shai-Hulud i zaprojektowano do pozyskiwania tokenów npm i GitHub, poświadczeń chmurowych, kluczy SSH, danych Kubernetes, sekretów z plików .env oraz wybranych danych z narzędzi deweloperskich i środowisk AI.
- Automatyczne uruchomienie przy instalacji pakietu
- Kradzież poświadczeń i sekretów z hosta oraz CI/CD
- Mechanizmy persistence i zdalnego wykonywania kodu
- Próby samoreplikacji przez repozytoria i workflow
Kontekst / historia
Incydent wpisuje się w szerszy trend ataków typu supply chain powiązanych z kampaniami wykorzystującymi warianty robaka Shai-Hulud. W ostatnich miesiącach podobne techniki służyły do kompromitowania pakietów open source i przejmowania środowisk deweloperskich przez zaufane kanały dystrybucji.
W przypadku tensorlake złośliwy kod trafił do głównej gałęzi repozytorium projektu, a następnie został opublikowany przy użyciu istniejącego procesu release. Taki model utrudnia wykrycie zagrożenia wyłącznie na podstawie reputacji pakietu lub faktu, że publikacja pochodziła z legalnego pipeline’u. Według dostępnych analiz pierwszy złośliwy commit pojawił się 7 października 2026 roku około 01:20 UTC, a wersja 0.5.144 opublikowano dzień później.
Analiza techniczna
Najgroźniejszym elementem incydentu był sposób aktywacji ładunku. Złośliwy kod uruchamiał się przez hook preinstall, więc do rozpoczęcia infekcji wystarczała sama instalacja zależności. Nie było konieczne ręczne uruchomienie aplikacji ani dodatkowa interakcja użytkownika.
Analizy wskazują, że pakiet zawierał obfuskowany loader uruchamiający dalszy payload przy użyciu środowiska Bun. Główny komponent malware odpowiadał za pozyskiwanie poświadczeń z lokalnego hosta, odczyt sekretów z plików konfiguracyjnych i środowisk CI, eksfiltrację danych z Kubernetes i HashiCorp Vault oraz kradzież kluczy SSH, tokenów GitHub i npm, a także poświadczeń AWS. Dodatkowy komponent miał umożliwiać pozyskiwanie danych przeglądarkowych.
Złośliwy kod wykazywał również właściwości robaka. Według badaczy próbował identyfikować zasoby powiązane z tożsamością ofiary, a następnie przygotowywać kolejne skażone publikacje. W analizach wskazano również artefakty sugerujące modyfikowanie repozytoriów przez dodawanie plików .claude/settings.json oraz .vscode/tasks.json, co mogło prowadzić do ponownego uruchamiania malware po otwarciu projektu w narzędziach deweloperskich.
Istotnym elementem była też komunikacja z infrastrukturą sterującą. Jeden z opisanych wariantów wykorzystywał kontrakt Ethereum do rozwiązywania adresu endpointu C2, a jako kanał zapasowy wykorzystywał GitHub do przechowywania lub etapowania wykradzionych danych. Takie podejście utrudnia blokowanie całej infrastruktury atakującego i zwiększa odporność kampanii na proste działania obronne.
Szczególnie agresywnym składnikiem był tak zwany hostage token. Z dostępnych analiz wynika, że komponent monitorował ważność przejętego tokenu GitHub i w przypadku jego unieważnienia mógł uruchamiać dodatkowy kod PowerShell dostarczony przez operatora. W praktyce oznacza to próbę zniechęcenia ofiary do szybkiej reakcji lub eskalację szkód po wykryciu naruszenia.
Konsekwencje / ryzyko
Skutki kompromitacji wykraczają daleko poza pojedynczy pakiet npm. Jeśli złośliwa wersja została zainstalowana na stacji deweloperskiej, runnerze CI, serwerze buildowym lub w środowisku platform engineering, atakujący mogli uzyskać dostęp do szerokiego zestawu sekretów i tożsamości technicznych.
- Przejęcie kont npm i publikacja kolejnych złośliwych wydań
- Kompromitacja kont GitHub i modyfikacja repozytoriów
- Wyciek poświadczeń chmurowych i dostęp do infrastruktury
- Uzyskanie dostępu do klastrów Kubernetes i sekretów Vault
- Kradzież danych z przeglądarek, portfeli kryptowalutowych i narzędzi komunikacyjnych
- Utrzymanie dostępu po usunięciu zależności dzięki mechanizmom persistence
- Rozprzestrzenienie infekcji na kolejne projekty i organizacje
Ryzyko jest szczególnie wysokie w organizacjach korzystających z automatycznych procesów budowania, zaufanego publikowania pakietów oraz wspólnych sekretów dostępnych z poziomu hosta lub pipeline’u. Nawet krótka obecność złośliwego pakietu w środowisku mogła otworzyć drogę do dalszych etapów ataku.
Rekomendacje
Organizacje powinny traktować instalację tensorlake@0.5.144 jako pełnoprawny incydent bezpieczeństwa, a nie jedynie problem z aktualizacją zależności. Konieczne jest uruchomienie procedur IR oraz założenie, że wszystkie sekrety dostępne dla procesu instalacyjnego mogły zostać ujawnione.
- Natychmiast zidentyfikować systemy, kontenery, lockfile i cache zawierające wersję
0.5.144 - Usunąć skażoną wersję z lokalnych mirrorów, proxy i repozytoriów artefaktów
- Przeprowadzić pełną rotację tokenów npm, GitHub, kluczy SSH, poświadczeń chmurowych, sekretów Kubernetes i Vault oraz danych z plików
.env - Sprawdzić historię publikacji pakietów, workflow GitHub Actions, commitów i nieautoryzowanych zmian w repozytoriach
- Zweryfikować obecność plików
.claude/settings.json,.vscode/tasks.jsonoraz innych artefaktów persistence - Przeanalizować hosty pod kątem uruchomień Bun, PowerShell i procesów monitorujących tokeny
- Skontrolować połączenia sieciowe i potencjalną eksfiltrację danych do zewnętrznych endpointów lub repozytoriów
- Rozważyć odtworzenie środowisk buildowych i stacji deweloperskich z zaufanego obrazu
- Wdrożyć monitorowanie hooków instalacyjnych oraz polityki blokujące nieautoryzowane
preinstallipostinstall - Ograniczyć zakres sekretów dostępnych dla procesów budowania zgodnie z zasadą najmniejszych uprawnień
Długofalowo warto wzmocnić kontrolę łańcucha dostaw przez skanowanie zależności, analizę provenance, wymuszanie zatwierdzonych źródeł pakietów, izolację środowisk buildowych oraz ciągłe monitorowanie zmian w krytycznych repozytoriach open source.
Podsumowanie
Przypadek tensorlake pokazuje, że współczesne ataki na ekosystem npm łączą cechy infostealera, robaka i backdoora w jednym ładunku uruchamianym już podczas instalacji zależności. Kompromitacja zaufanego pakietu, publikacja przez legalny proces release i szeroki zakres kradzionych sekretów sprawiają, że incydent należy traktować jako pełnoskalowe zagrożenie dla łańcucha dostaw oprogramowania. Dla zespołów bezpieczeństwa kluczowe są szybka identyfikacja narażonych środowisk, rotacja wszystkich potencjalnie ujawnionych poświadczeń oraz weryfikacja, czy infekcja nie doprowadziła do dalszego rozprzestrzenienia się w organizacji.
Źródła
- The Hacker News — https://thehackernews.com/2026/10/tensorlake-npm-package-compromised-to.html
- StepSecurity — https://www.stepsecurity.io/blog/tensorlake-npm-compromised-hostage-token-worm
- Sonatype — https://www.sonatype.com/blog/hijacked-tensorlake-npm-turned-install-into-credential-risk
- Aikido Security — https://www.aikido.dev/blog/tensorlake-npm-package-compromised
- Endor Labs — https://www.endorlabs.com/learn/tensorlake-npm-package-compromised-by-shai-hulud-in-latest-software-supply-chain-attack