PyTorch Lightning malware – co zrobić jeśli zainstalowałeś wersję 2.6.2 albo 2.6.3

Osiemnaście minut wystarczyło Socket Research Team, żeby wyłapać atak na pakiet lightning w repozytorium PyPI. 30 kwietnia 2026 ktoś przejął konto GitHub projektu PyTorch Lightning i wypuścił dwie złośliwe wersje pakietu, oznaczone jako 2.6.2 oraz 2.6.3. Każdy, kto w tym oknie czasowym zrobił pip install lightning albo pip install lightning --upgrade, ściągnął na swój komputer ukryty payload. Malware aktywował się automatycznie przy pierwszym imporcie pakietu i zaczynał kraść klucze SSH, tokeny GitHub, credentials chmurowe oraz portfele kryptowalut. PyPI postawił pakiet w kwarantannie, deweloperzy projektu wycofali złośliwe wersje, a najnowszą bezpieczną wersją pozostaje 2.6.1. Ataku doświadczyły setki tysięcy deweloperów dziennie, którzy używają tego pakietu do trenowania modeli AI. To jeden z większych incydentów supply chain ataków na PyPI w tym roku, podobnie jak wcześniejszy atak na axios w npm czy supply chain compromise LiteLLM.

Co dokładnie się stało z pakietem PyTorch Lightning

PyTorch Lightning to popularna biblioteka do trenowania modeli AI w Pythonie, dystrybuowana przez PyPI pod nazwą pakietu lightning. Statystyki użycia są imponujące: setki tysięcy pobrań dziennie, miliony miesięcznie. To jedno z narzędzi bazowych dla każdego, kto pracuje w ML albo deep learning – od indywidualnych researcherów, przez startupy AI, po duże korporacje. Właśnie ta skala czyni ten incydent jednym z najbardziej poważnych w 2026.

30 kwietnia 2026 ktoś opublikował na PyPI dwie wersje, których nie powinno być – 2.6.2 i 2.6.3. Obie zawierały złośliwy kod ukryty w katalogu _runtime/, składający się z downloadera oraz obfuskowanego payloadu JavaScript. Modyfikacja pliku __init__.py powodowała, że payload uruchamiał się automatycznie przy pierwszym imporcie pakietu, czyli przy zwykłym import lightning w kodzie Pythona. Bez żadnych dodatkowych kroków od użytkownika, bez widocznych komunikatów, bez wpisu w logach.

Atak był brzytko skonstruowany: użytkownik nie musiał nic kliknąć ani uruchomić. Wystarczyło zaimportować pakiet, którego używa codziennie do trenowania modeli.

Detekcja przyszła z Socket Research Team – flagowali złośliwe wersje już 18 minut po publikacji. Kolejne firmy researchu (Aikido Security, OX Security, StepSecurity, Semgrep) potwierdziły kompromitację w ciągu godzin. PyPI administratorzy postawili pakiet w kwarantannie, zespół PyTorch Lightning zaczął rollback. Aktualnie złośliwe wersje 2.6.2 i 2.6.3 zostały usunięte, kwarantanna zdjęta, a jedyną bezpieczną wersją do instalacji pozostaje 2.6.1.

Jak działa atak – 5 etapów exec malware’u

Sekwencja ataku jest klasyczna dla supply chain compromises, choć tu wykonana wyjątkowo precyzyjnie. Cały łańcuch wykonuje się automatycznie i cicho – od instalacji pakietu po wysłanie kluczy do atakującego.

Etap pierwszy to instalacja. Każdy pip install lightning==2.6.2, pip install lightning==2.6.3 albo pip install lightning --upgrade w czasie kilku godzin 30 kwietnia ściągał skompromitowaną wersję. Następnie przy pierwszym imporcie modyfikowany __init__.py automatycznie uruchamiał background process, zaraz gdy kod Pythona dotykał pakietu. Trzeci krok to ukryty katalog _runtime/ zawierający downloadera. Z kolei czwarty etap obejmował obfuskowany payload JavaScript, który skanował lokalny system w poszukiwaniu wrażliwych danych. Na końcu następowała exfiltracja danych do repozytoriów GitHub kontrolowanych przez atakujących.

Co konkretnie kradł payload? Lista jest długa i niepokojąca. Klucze SSH z ~/.ssh/. Historię shella z .bash_history oraz .zsh_history. Credentials chmurowe AWS, GCP i Azure z katalogów konfiguracyjnych. Tokeny GitHub i npm z ~/.netrc, ~/.npmrc oraz zmiennych środowiskowych. Portfele kryptowalut różnych klientów. Dodatkowo, jeśli payload miał dostęp do tokenu GitHub, próbował zatruć inne repozytoria użytkownika, pushując złośliwe commity.

Kontekst też jest ważny. Researcherzy z The Hacker News uważają, że atak na lightning to ekstensja kampanii “Mini Shai-Hulud”, która wcześniej (w tym tygodniu) zaatakowała pakiety SAP-related w npm. Innymi słowy, mamy do czynienia z jedną grupą działającą równolegle w ekosystemach Python i JavaScript. Wzór jest powtarzalny – przejmowanie kont GitHub maintainerów popularnych pakietów, wypuszczanie zatrutej wersji, wysysanie credentials w ciągu godzin pierwszego dostępu.

Co to znaczy dla polskich zespołów ML i AI

Polskie zespoły AI/ML masowo używają PyTorch Lightning – od labs uczelnianych, przez startupy AI, po działy data science w dużych firmach. Statystyki są jasne: jeśli pracujesz z deep learning w Pythonie, prawie na pewno masz lub miałeś lightning w swoim requirements.txt. Dlatego każdy zespół, który robił pip install w ciągu kilku godzin 30 kwietnia 2026, powinien przeprowadzić audyt.

W projektach klienckich zalecamy w takich sytuacjach trzy rzeczy. Po pierwsze, sprawdzić wszystkie środowiska wirtualne i CI pipeline’y, czy gdzieś nie zainstalowała się wersja 2.6.2 albo 2.6.3. Komenda pip show lightning pokaże aktualną wersję, a pip list --outdated pokaże, co czeka na update. Po drugie, jeśli któraś z tych wersji jest zainstalowana – traktować zainfekowany system jako compromised, czyli zrotować wszystkie klucze SSH, GitHub tokens, npm tokens i credentials do AWS/GCP/Azure. Po trzecie, audyt repozytoriów GitHub, do których zainfekowany system miał dostęp – czy nie ma podejrzanych commitów wrzuconych w ostatnich godzinach.

Supply chain attacks na PyPI i npm to dziś nowa norma, nie wyjątek. Każdy zespół AI/ML musi mieć politykę reagowania na takie incydenty.

W ostatnich miesiącach widzieliśmy supply chain attack na Bitwarden CLI, LiteLLM compromise związany z wyciekiem 4 TB danych Mercor oraz VECT 2.0 ransomware z błędem typu vibe coded. Wzór jest jasny: 2026 to rok, w którym ataki na ekosystem open source przyspieszyły. Polski zespół, który chce być gotowy, powinien wdrożyć dwa proste mechanizmy. Pierwszy to lockfile z dokładnymi wersjami pakietów (pip freeze > requirements.txt albo poetry.lock). Drugi to monitoring nowych wersji przez narzędzia typu Socket, Snyk czy GitHub Dependabot z security alertami.

Pierwsza Misja AI · Kodożercy

Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa

Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja, ataki na łańcuch dostaw. Zanim zaczniesz się bać, zacznij rozumieć.

Poznaj pełny program →

FAQ – co teraz zrobić jako developer ML/AI

Jak sprawdzić czy mam u siebie zainfekowaną wersję PyTorch Lightning?

Uruchom pip show lightning w każdym środowisku wirtualnym oraz w CI pipeline’ach. Jeśli pole “Version” pokazuje 2.6.2 albo 2.6.3, masz problem. Sprawdź też lockfile: requirements.txt, poetry.lock, Pipfile.lock. Pamiętaj o Docker images zbudowanych po 30 kwietnia 2026 – one też mogą zawierać złośliwą wersję, jeśli Dockerfile nie pinuje do konkretnej safe version.

Co zrobić jeśli zainstalowałem 2.6.2 albo 2.6.3 i zaimportowałem pakiet?

Traktuj system jako compromised i działaj szybko. Pierwszy krok – rotacja kluczy SSH (~/.ssh/), GitHub Personal Access Tokens, npm tokens, credentials chmurowych (AWS, GCP, Azure). Drugi krok – audyt commitów w repozytoriach, do których system miał dostęp w ostatnich godzinach. Trzeci krok – downgrade do pip install lightning==2.6.1 i skanowanie systemu narzędziem antywirusowym albo EDR.

Czy zainfekowany pakiet trafił też do moich Docker images?

Możliwe, jeśli build odbył się 30 kwietnia 2026 z pip install lightning bez pinowanej wersji albo z lightning>=2.6.0. Sprawdź swoje rejestry Docker, daty buildów i teorię dependencji. Najbezpieczniej rebuildować wszystkie obrazy z jawnym lightning==2.6.1 w Dockerfile albo requirements i zaktualizować deploymenty.

Czy moja firma powinna wstrzymać używanie PyTorch Lightning?

Nie ma takiej potrzeby. Wersja 2.6.1 jest bezpieczna, a zespół Lightning szybko zareagował na incydent. Sam pakiet pozostaje fundamentalnym narzędziem dla deep learning w Pythonie. Lekcją jest natomiast wprowadzenie pinowanych wersji w requirements oraz monitoringu typu Socket albo Dependabot – to standardowa higiena, którą warto mieć niezależnie od konkretnego pakietu.

Podsumowanie

PyTorch Lightning malware to incydent z 30 kwietnia 2026, w którym przejęte konto GitHub maintainera pozwoliło atakującym opublikować na PyPI dwie złośliwe wersje pakietu (2.6.2 i 2.6.3). Payload uruchamiał się automatycznie przy pierwszym imporcie i kradł klucze SSH, tokeny GitHub, credentials chmurowe oraz portfele kryptowalut, exfiltrując dane do repozytoriów atakujących. Socket wykrył atak w 18 minut, PyPI postawił pakiet w kwarantannie, a złośliwe wersje zostały usunięte. Bezpieczną wersją pozostaje 2.6.1. Co zyskała branża z tego incydentu? Kolejny dowód, że supply chain attacks na PyPI to nie wyjątek, lecz nowa norma. Co powinien zrobić każdy polski zespół ML/AI? Sprawdzić środowiska wirtualne i CI, zrotować klucze jeśli zainfekowana wersja była zainstalowana, oraz wdrożyć pinowanie wersji plus monitoring narzędziami typu Socket lub Dependabot. To standardowa higiena bezpieczeństwa w czasach, gdy ekosystem open source jest celem coraz bardziej regularnych ataków.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.