Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent związany z PyTorch Lightning pokazuje, jak poważnym zagrożeniem dla organizacji rozwijających systemy sztucznej inteligencji są dziś ataki na łańcuch dostaw oprogramowania. W tym przypadku złośliwe wersje popularnej biblioteki dostępnej w rejestrze PyPI zostały opublikowane jako pozornie legalna aktualizacja, a szkodliwy kod uruchamiał się już na etapie importu pakietu.
Taki scenariusz jest szczególnie niebezpieczny dla środowisk deweloperskich, laboratoriów ML, notebooków badawczych, pipeline’ów CI/CD oraz infrastruktury chmurowej. W praktyce pojedyncza biblioteka może stać się punktem wejścia do przejęcia sekretów, kont serwisowych i dostępu do krytycznych zasobów organizacji.
W skrócie
- Kompromitacja objęła wersje 2.6.2 oraz 2.6.3 pakietu PyTorch Lightning w PyPI.
- Złośliwy kod działał jak stealer poświadczeń i aktywował się przy imporcie modułu.
- Łańcuch wykonania obejmował uruchomienie ukrytego procesu, pobranie środowiska Bun i wykonanie zaciemnionego ładunku.
- Atak był ukierunkowany na pliki .env, tokeny API, dane przeglądarek oraz poświadczenia do usług chmurowych.
- Utrzymujący projekt zalecili natychmiastowe usunięcie podatnych wersji, rotację sekretów i powrót do wersji 2.6.1.
Kontekst / historia
PyTorch Lightning to szeroko stosowana warstwa abstrakcji dla frameworka PyTorch, wykorzystywana do trenowania, testowania i wdrażania modeli uczenia głębokiego. Z uwagi na dużą popularność w środowiskach badawczych i produkcyjnych kompromitacja tej biblioteki ma znaczenie znacznie wykraczające poza pojedynczy projekt open source.
Informacje o incydencie pojawiły się pod koniec kwietnia 2026 roku. Oficjalne advisory projektu wskazało, że naruszenie dotyczy opublikowanych wersji 2.6.2 i 2.6.3, które zawierały mechanizm wykradania poświadczeń. Utrzymujący usunęli złośliwe wydania z rejestru, rozpoczęli analizę źródła kompromitacji i wskazali wersję 2.6.1 jako ostatnie bezpieczne wydanie.
Zdarzenie wpisuje się w rosnący trend ataków wymierzonych w zależności programistyczne wykorzystywane w obszarze AI i data science. To właśnie tam środowiska robocze często mają jednocześnie dostęp do repozytoriów kodu, zasobów treningowych, sekretów aplikacyjnych i kont chmurowych.
Analiza techniczna
Najbardziej niepokojącym elementem incydentu był mechanizm aktywacji ładunku. Złośliwa funkcjonalność uruchamiała się po zwykłym imporcie biblioteki, bez konieczności wykonywania dodatkowych komend czy uruchamiania podejrzanych skryptów. Taki sposób działania znacząco zwiększa skuteczność infekcji, ponieważ import pakietu jest naturalnym etapem pracy aplikacji, notebooka lub procesu treningowego.
Według dostępnych analiz złośliwe wydania inicjowały ukryty łańcuch wykonania, który działał w tle i przygotowywał środowisko do uruchomienia właściwego payloadu. Następnie pobierane było środowisko Bun służące do wykonywania kodu JavaScript, po czym uruchamiano silnie zaciemniony ładunek o charakterze malware.
Payload był nastawiony na pozyskanie danych wrażliwych z lokalnego środowiska i popularnych narzędzi deweloperskich. Na liście celów znajdowały się między innymi:
- pliki środowiskowe .env,
- tokeny GitHub,
- klucze API,
- dane zapisane w przeglądarkach takich jak Chrome, Firefox i Brave,
- poświadczenia do AWS, Azure i Google Cloud.
Z perspektywy bezpieczeństwa istotne jest również to, że opisy incydentu wskazują nie tylko na klasyczne wykradanie danych, ale także na możliwość zdalnego wykonywania poleceń. To podnosi wagę zagrożenia z poziomu kradzieży sekretów do potencjalnie pełnej kompromitacji stacji roboczej, kontenera lub hosta wykorzystywanego do budowania artefaktów.
Dodatkowym problemem jest charakter samego ataku na repozytorium pakietów. Nawet jeśli złośliwe wersje były dostępne stosunkowo krótko, mogły zostać pobrane przez automatyczne procesy buildów, cache zależności, środowiska tymczasowe oraz lockfile używane w pipeline’ach. Oznacza to, że usunięcie pakietu z rejestru nie kończy incydentu po stronie użytkowników.
Konsekwencje / ryzyko
Ryzyko wynikające z kompromitacji PyTorch Lightning należy oceniać jako krytyczne, zwłaszcza w organizacjach wykorzystujących AI w środowiskach produkcyjnych. Typowy host deweloperski lub treningowy może przechowywać jednocześnie dostęp do prywatnych repozytoriów, systemów CI/CD, magazynów artefaktów, usług chmurowych oraz baz danych.
Wyciek takich danych może prowadzić do przejęcia kont chmurowych, kradzieży modeli i danych treningowych, kompromitacji kolejnych pipeline’ów oraz wdrożenia backdoorów do aplikacji produkcyjnych. W najgorszym scenariuszu pojedyncza zainfekowana zależność staje się punktem startowym dla dalszego rozprzestrzeniania się ataku w całym ekosystemie dostawców i klientów.
Największe zagrożenie dotyczy organizacji automatycznie aktualizujących zależności lub uruchamiających trening modeli w środowiskach z szerokimi uprawnieniami. W takich warunkach nawet krótkotrwała publikacja złośliwego wydania może wystarczyć do eskalacji incydentu z poziomu pojedynczego dewelopera do poziomu całej infrastruktury.
Rekomendacje
Organizacje, które mogły korzystać z wersji 2.6.2 lub 2.6.3, powinny traktować każde takie środowisko jako potencjalnie skompromitowane. Reakcja nie powinna ograniczać się wyłącznie do usunięcia pakietu, ponieważ najważniejszym problemem są już potencjalnie wykradzione sekrety i dalsze możliwości dostępu atakującego.
- Należy natychmiast zidentyfikować hosty, kontenery, notebooki i pipeline’y używające wskazanych wersji.
- Trzeba usunąć podatne wydania i przypiąć zależności do wersji 2.6.1 lub innej potwierdzonej jako bezpieczna.
- Konieczna jest pełna rotacja wszystkich sekretów obecnych w środowisku, w tym kluczy API, tokenów dostępowych, kluczy SSH i poświadczeń kont serwisowych.
- Warto przeanalizować logi chmurowe, repozytoryjne i CI/CD pod kątem nietypowych logowań, użycia tokenów i nowych artefaktów.
- Zalecana jest odbudowa systemów z zaufanego obrazu bazowego zamiast prób czyszczenia środowiska na miejscu.
- Należy również zweryfikować cache zależności, lockfile oraz wewnętrzne mirrory pakietów.
W dłuższej perspektywie organizacje powinny wdrożyć praktyki ograniczające skutki podobnych incydentów. Obejmują one ścisłe pinningowanie wersji, kontrolę integralności pakietów, korzystanie z prywatnych repozytoriów pośredniczących, skanowanie zależności pod kątem anomalii oraz egzekwowanie zasady najmniejszych uprawnień dla środowisk deweloperskich i treningowych.
Podsumowanie
Kompromitacja PyTorch Lightning jest kolejnym sygnałem, że biblioteki wykorzystywane w ekosystemie AI stały się atrakcyjnym celem dla operatorów ataków supply chain. Złośliwe wersje 2.6.2 i 2.6.3 nie tylko wykradały poświadczenia, ale aktywowały kod już przy imporcie pakietu, co znacząco zwiększało skuteczność ataku.
Dla zespołów bezpieczeństwa oznacza to konieczność traktowania środowisk ML i AI na równi z krytycznymi elementami infrastruktury produkcyjnej. Ochrona łańcucha dostaw oprogramowania nie może dziś kończyć się na klasycznych aplikacjach webowych i backendowych, lecz musi obejmować również narzędzia data science, biblioteki treningowe i rejestry pakietów.
Źródła
- https://securityaffairs.com/191732/ai/malicious-pytorch-lightning-update-hits-ai-supply-chain-security.html
- https://github.com/Lightning-AI/pytorch-lightning/security/advisories/GHSA-w37p-236h-pfx3
- https://github.com/Lightning-AI/pytorch-lightning/security/advisories
- https://www.sonatype.com/blog/malicious-pytorch-lightning-packages-found-on-pypi?hs_amp=true
- https://semgrep.dev/blog/2026/malicious-dependency-in-pytorch-lightning-used-for-ai-training