Złośliwy pakiet PyTorch Lightning 2.6.3 na PyPI uruchamiał stealera już przy imporcie biblioteki

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla środowisk developerskich, badawczych i produkcyjnych. Najnowszy incydent związany z pakietem lightning w wersji 2.6.3, opublikowanym w repozytorium PyPI, pokazuje, że nawet popularne biblioteki wykorzystywane w ekosystemie AI i machine learning mogą zostać użyte do dystrybucji malware.

W tym przypadku zagrożenie było szczególnie niebezpieczne, ponieważ złośliwy kod aktywował się już w momencie wykonania import lightning. Oznacza to, że użytkownik nie musiał uruchamiać żadnej konkretnej funkcji aplikacyjnej ani dodatkowego skryptu, aby doszło do pobrania i uruchomienia komponentu kradnącego dane.

W skrócie

• Złośliwa wersja pakietu została opublikowana jako lightning==2.6.3.
• Po imporcie biblioteki uruchamiany był ukryty łańcuch wykonania działający w tle.
• Mechanizm pobierał runtime JavaScript Bun, a następnie wykonywał silnie zaciemniony plik router_runtime.js.
• Payload był ukierunkowany na kradzież sekretów, tokenów, poświadczeń chmurowych i danych z przeglądarek.
• Użytkownicy, którzy uruchomili tę wersję, powinni traktować wszystkie obecne w środowisku sekrety jako potencjalnie skompromitowane.

Kontekst / historia

PyTorch Lightning to szeroko wykorzystywany framework upraszczający trenowanie, pretraining oraz fine-tuning modeli AI. Ze względu na swoją popularność jest obecny zarówno w notebookach badawczych, jak i w środowiskach CI/CD, kontenerach, serwerach GPU oraz infrastrukturze chmurowej. Taka skala użycia sprawia, że kompromitacja pojedynczego pakietu może mieć bardzo szeroki zasięg.

Incydent został publicznie zgłoszony 30 kwietnia 2026 roku jako możliwy atak na łańcuch dostaw. Następnie ujawniono, że wydanie 2.6.3 zawierało nieautoryzowane komponenty wykonywane automatycznie przy imporcie modułu. Bezpieczna wersja pakietu została przywrócona, a wydanie 2.6.3 wycofano z użycia. Równolegle rozpoczęto analizę tego, w jaki sposób mogło dojść do naruszenia procesu build lub release pipeline.

Analiza techniczna

Technicznie był to klasyczny kompromis pakietu w publicznym rejestrze oprogramowania, ale z nietypowo agresywnym mechanizmem aktywacji. Złośliwy kod nie wymagał żadnej akcji poza zwykłym importem biblioteki, co znacząco zwiększało skuteczność ataku i utrudniało jego szybkie zauważenie.

Łańcuch wykonania obejmował kilka etapów. Najpierw w pliku inicjalizacyjnym pakietu umieszczono logikę uruchamiającą proces podrzędny w tle. Następnie proces wykonywał skrypt start.py z katalogu runtime. Kolejnym krokiem było pobranie Bun w wersji 1.3.13 z zewnętrznego źródła. Ostatecznie uruchamiano silnie zaciemniony plik router_runtime.js o rozmiarze około 11,4 MB, przygotowany do pracy bez widocznych komunikatów w standardowym wyjściu i błędach.

Z analizy artefaktów wynika, że payload posiadał cechy typowe dla infostealera. Funkcjonalność obejmowała przeszukiwanie plików .env, odczyt zmiennych środowiskowych, zbieranie tokenów GitHub, poszukiwanie sekretów chmurowych oraz dostęp do danych przechowywanych w przeglądarkach Chrome, Firefox i Brave. Analiza wskazywała również na możliwość wykonywania poleceń systemowych, co zwiększało ryzyko dalszej eskalacji.

Szczególnie alarmujące były odwołania do metadanych instancji chmurowych, interfejsów OAuth, menedżerów sekretów oraz API platform developerskich. Taki zestaw możliwości sugeruje, że celem atakujących nie była wyłącznie lokalna kradzież haseł, ale również przejęcie dostępu do infrastruktury organizacji, repozytoriów kodu oraz zasobów uruchomieniowych.

Dodatkowym czynnikiem zwiększającym skuteczność ataku było pełne wyciszenie procesu. Malware działał w tle, bez żądania interakcji i bez oczywistych oznak awarii, co mogło uśpić czujność osób uruchamiających skrypty treningowe, notebooki lub pipeline’y automatyzacji.

Konsekwencje / ryzyko

Ryzyko związane z tym incydentem należy ocenić jako wysokie. Pakiet był używany w środowiskach, które często przechowują dużą liczbę sekretów operacyjnych i mają szerokie uprawnienia do usług krytycznych. W praktyce skutki kompromitacji mogły obejmować nie tylko wyciek danych uwierzytelniających, ale także przejęcie dostępu do elementów infrastruktury organizacyjnej.

• Wyciek kluczy API, tokenów i sekretów aplikacyjnych.
• Kompromitację kont chmurowych oraz zasobów obliczeniowych, w tym środowisk GPU.
• Przejęcie dostępu do repozytoriów kodu, pipeline’ów CI/CD i systemów automatyzacji.
• Wykradzenie ciasteczek, zapisanych haseł i innych danych z przeglądarek.
• Możliwość dalszego ruchu bocznego po infrastrukturze organizacji.

Najbardziej narażone są zespoły ML i AI, które uruchamiają zależności Python w notebookach, na stacjach roboczych, w kontenerach oraz w środowiskach badawczych z szerokim dostępem do chmury i prywatnych repozytoriów. W takich warunkach pojedynczy złośliwy import może stanowić punkt wejścia do dużo szerszego incydentu bezpieczeństwa.

Nawet jeśli liczba potwierdzonych przypadków użycia złośliwej wersji była ograniczona, każdy host, na którym ją uruchomiono, należy traktować jako potencjalnie naruszony. Nie jest to wyłącznie problem wadliwej zależności, lecz pełnoprawny incydent bezpieczeństwa wymagający reakcji operacyjnej.

Rekomendacje

Organizacje, które mogły korzystać z lightning==2.6.3, powinny przejść w tryb incident response. Najważniejsze jest szybkie ustalenie zasięgu ekspozycji oraz potraktowanie wszystkich sekretów obecnych w zagrożonych środowiskach jako potencjalnie skompromitowanych.

• Natychmiast zidentyfikować hosty, kontenery, notebooki i pipeline’y, w których zainstalowano lub uruchomiono tę wersję pakietu.
• Sprawdzić logi budowy obrazów, historię poleceń, lockfile zależności i artefakty pipeline’ów.
• Przeprowadzić pełną rotację kluczy API, tokenów GitHub, sekretów aplikacyjnych oraz poświadczeń AWS, Azure i GCP.
• Unieważnić aktywne sesje przeglądarek i odświeżyć zapisane dane uwierzytelniające.
• Przeanalizować ruch sieciowy wychodzący z podejrzanych systemów.
• Przeskanować stacje robocze i serwery pod kątem artefaktów związanych z Bun, start.py, router_runtime.js oraz nietypowych procesów potomnych Pythona.
• Odtworzyć obrazy kontenerów i środowiska CI/CD z zaufanych źródeł.

W dłuższej perspektywie warto wdrożyć mechanizmy, które ograniczą skutki podobnych incydentów w przyszłości.

• Stosować pinning wersji i kontrolę integralności pakietów.
• Wykorzystywać wewnętrzne proxy lub mirror repozytoriów pakietów.
• Uruchomić Software Composition Analysis z politykami blokującymi nowe lub niezweryfikowane wydania.
• Wdrożyć detekcję zachowań typu „import uruchamia proces w tle”.
• Ograniczyć uprawnienia środowisk deweloperskich i notebooków ML zgodnie z zasadą najmniejszych uprawnień.
• Segmentować dostęp do sekretów i rozdzielać role między treningiem modeli a operacjami produkcyjnymi.

Podsumowanie

Incydent z PyTorch Lightning 2.6.3 pokazuje, że ataki na ekosystemy open source są coraz lepiej dopasowane do środowisk o wysokiej wartości biznesowej, takich jak platformy AI i infrastruktura chmurowa. Najgroźniejszym elementem tej kampanii był mechanizm uruchamiania malware już przy samym imporcie biblioteki, bez widocznej interakcji użytkownika.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że menedżery pakietów, pipeline’y build/release oraz środowiska developerskie muszą być traktowane jako pełnoprawna powierzchnia ataku. Jeśli organizacja miała styczność z podatną wersją, priorytetem powinny być analiza zasięgu, rotacja sekretów oraz pełna weryfikacja integralności środowisk.

Źródła

1. https://www.bleepingcomputer.com/news/security/backdoored-pytorch-lightning-package-drops-credential-stealer/
2. https://github.com/Lightning-AI/pytorch-lightning/issues/21689