Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla środowisk deweloperskich, badawczych i produkcyjnych. Najnowszy incydent związany z pakietem PyTorch Lightning pokazuje, że nawet popularna biblioteka wykorzystywana w projektach AI może zostać użyta jako nośnik złośliwego kodu.
Problem dotyczył wydania lightning==2.6.3 opublikowanego w repozytorium PyPI. W pakiecie umieszczono ukryty mechanizm wykonania, który prowadził do pobrania i uruchomienia malware kradnącego poświadczenia oraz inne wrażliwe dane z systemu ofiary.
W skrócie
- Wersja 2.6.3 pakietu Lightning została uznana za złośliwą.
- Aktywacja następowała automatycznie już po wykonaniu
import lightning. - Mechanizm uruchamiał proces w tle, pobierał runtime Bun i wykonywał zaciemniony skrypt JavaScript.
- Ładunek był ukierunkowany na kradzież plików
.env, tokenów GitHub, sekretów chmurowych oraz danych z przeglądarek. - Użytkownikom zalecono natychmiastowe usunięcie pakietu i rotację wszystkich zagrożonych sekretów.
Kontekst / historia
PyTorch Lightning, rozwijany obecnie jako Lightning, to szeroko stosowany framework dla uczenia głębokiego i trenowania modeli AI. Ze względu na dużą popularność biblioteki każdy incydent bezpieczeństwa dotyczący jej procesu publikacji może mieć szeroki wpływ na organizacje wykorzystujące narzędzia MLOps, notebooki badawcze i pipeline’y CI/CD.
Incydent został publicznie nagłośniony 30 kwietnia 2026 roku, gdy wykryto, że wydanie 2.6.3 zawiera elementy niezgodne z oczekiwanym zachowaniem biblioteki. Złośliwe wydanie zostało następnie wycofane, a użytkownikom wskazano bezpieczne wersje do dalszego użycia.
To klasyczny przykład ataku supply chain. Napastnik nie musi bezpośrednio włamywać się do środowiska końcowego ofiary, jeśli uda mu się umieścić złośliwy kod w zaufanej zależności używanej przez programistów, badaczy danych i systemy automatyzacji.
Analiza techniczna
Technicznie incydent był szczególnie groźny, ponieważ próg aktywacji był bardzo niski. Wystarczało samo zaimportowanie biblioteki, aby uruchomić ukryty kod. Taki model działania znacząco utrudnia wykrycie zagrożenia, ponieważ użytkownik nie musi wywoływać żadnej podejrzanej funkcji.
Zgodnie z analizą, mechanizm inicjalizacyjny tworzył proces potomny uruchamiany w tle. Działanie było zaprojektowane tak, aby ograniczyć widoczność anomalii: tłumiono komunikaty standardowego wyjścia i błędów, co zmniejszało szansę na szybkie zauważenie incydentu.
Następny etap obejmował uruchomienie komponentu pobierającego zewnętrzny runtime Bun, a następnie wykonanie silnie zaciemnionego pliku router_runtime.js. Tego rodzaju zaciemnianie utrudnia analizę statyczną, detekcję sygnaturową oraz szybką ocenę pełnego zakresu funkcji złośliwego kodu.
Analiza artefaktu wskazywała na funkcjonalność typową dla stealerów informacji. Zaobserwowano odniesienia do:
- plików
.envi zmiennych środowiskowych, - mechanizmów wykonywania poleceń systemowych,
- danych przechowywanych przez Chrome, Firefox i Brave,
- webhooków oraz kanałów eksfiltracji danych,
- interfejsów usług AWS, Azure i Google Cloud,
- endpointów powiązanych z GitHub API.
Szczególnie niepokojące było odwołanie do adresu 169.254.169.254, czyli lokalnego endpointu metadanych AWS IMDS. W praktyce oznacza to możliwość pozyskania tymczasowych poświadczeń przypisanych do instancji i workloadów działających w chmurze. Dla organizacji uruchamiających trening modeli, zadania inferencyjne lub pipeline’y budowania artefaktów taki wektor stanowi bardzo wysokie ryzyko.
Istotne jest również to, że złośliwe pliki znajdowały się bezpośrednio w opublikowanym artefakcie pakietu wraz z odpowiednimi wpisami integralności. Wskazuje to, że problem nie wynikał z lokalnej infekcji po stronie pojedynczego użytkownika, lecz był częścią oficjalnie dostarczonego wydania.
Konsekwencje / ryzyko
Skutki takiego incydentu mogą wykraczać daleko poza pojedynczą stację roboczą dewelopera. Jeśli podatna wersja została zainstalowana lub zaimportowana w środowisku roboczym, organizacja mogła narazić się na ujawnienie szerokiego zestawu danych uwierzytelniających i operacyjnych.
- Klucze API i sekrety aplikacyjne.
- Tokeny dostępu do repozytoriów kodu.
- Poświadczenia do usług chmurowych.
- Dane sesyjne i zapisane hasła z przeglądarek.
- Zawartość zmiennych środowiskowych oraz lokalnych konfiguracji.
Największe ryzyko dotyczy środowisk, w których Lightning był importowany automatycznie podczas testów, budowy obrazów, uruchamiania notebooków, zadań treningowych lub pracy kontenerów CI/CD. W takich przypadkach kompromitacja mogła prowadzić do wtórnych naruszeń, takich jak przejęcie kont chmurowych, dostęp do repozytoriów, modyfikacja pipeline’ów czy dalsze rozprzestrzenianie się ataku wewnątrz organizacji.
Incydent pokazuje też, jak niebezpieczne są zależności uruchamiające kod już na etapie importu modułu. To zachowanie często omija intuicyjne założenia administratorów i programistów, którzy koncentrują się na funkcjach wywoływanych jawnie, a nie na logice inicjalizacyjnej biblioteki.
Rekomendacje
Organizacje, które mogły korzystać z lightning==2.6.3, powinny traktować incydent jako potencjalne naruszenie poufności danych. Zalecana jest szybka reakcja obejmująca zarówno działania techniczne, jak i operacyjne.
- Natychmiast usunąć wersję 2.6.3 ze wszystkich środowisk deweloperskich, testowych i produkcyjnych.
- Zweryfikować historię instalacji pakietów w stacjach roboczych, notebookach, kontenerach i pipeline’ach CI/CD.
- Przeprowadzić rotację wszystkich sekretów, które mogły znajdować się w plikach
.env, zmiennych środowiskowych, przeglądarkach lub konfiguracjach chmurowych. - Unieważnić i ponownie wydać tokeny GitHub, klucze API oraz poświadczenia AWS, Azure i GCP.
- Przeanalizować logi sieciowe i telemetrię EDR pod kątem nietypowych połączeń wychodzących oraz uruchamiania procesów powiązanych z Bun i zaciemnionymi skryptami JavaScript.
- Skontrolować obrazy kontenerowe, cache zależności i artefakty buildów, aby wykluczyć utrwalenie złośliwych komponentów.
- Wdrożyć silniejsze kontrole supply chain, w tym pinning wersji, skanowanie zależności, weryfikację integralności i podpisywanie artefaktów.
- Ograniczyć dostęp workloadów do metadanych instancji, jeśli nie jest on wymagany, oraz stosować zasadę najmniejszych uprawnień.
Dobrą praktyką pozostaje również izolowanie środowisk budowy i treningu modeli od lokalnych przeglądarek oraz przechowywanych na stacjach roboczych sekretów. Taka segmentacja zmniejsza skutki potencjalnej kompromitacji zależności zewnętrznych.
Podsumowanie
Incydent z PyTorch Lightning to kolejny przykład dojrzałego ataku na łańcuch dostaw, w którym złośliwy kod został osadzony bezpośrednio w popularnym pakiecie ekosystemu programistycznego. Najgroźniejszym elementem była automatyczna aktywacja po zwykłym imporcie biblioteki oraz szeroki zakres danych objętych próbą kradzieży.
Dla zespołów DevSecOps, MLOps i administratorów bezpieczeństwa to wyraźny sygnał, że biblioteki AI i narzędzia data science muszą być objęte takimi samymi mechanizmami kontroli jak krytyczne komponenty backendowe. W praktyce oznacza to konieczność wzmacniania ochrony supply chain, monitorowania zależności i szybkiego reagowania na incydenty dotyczące publicznych rejestrów pakietów.
Źródła
- BleepingComputer — Backdoored PyTorch Lightning package drops credential stealer — https://www.bleepingcomputer.com/news/security/backdoored-pytorch-lightning-package-drops-credential-stealer/
- Lightning-AI / pytorch-lightning — Possible supply chain attack on version 2.6.3 — https://github.com/Lightning-AI/pytorch-lightning/issues/21689