Przekonaj się sam!
Pozostaw wiadomość, a skontaktuje się z Tobą nasz dedykowany doradca.
Wyślij nam wiadomość
0/10000
Horror w łańcuchu dostaw: Jak jeden pip install mógł przejąć całą Twoją infrastrukturę
Opublikowano: 11:30 24.03.2026
Cyberbezpieczeństwo
Jako inżynierowie i architekci systemów, codziennie operujemy w paradygmacie zaufania do ekosystemu open-source. Operacja pip install stała się odruchem tak naturalnym jak oddychanie – tysiące razy dziennie, na setkach tysięcy maszyn, bez cienia wątpliwości. 24 marca 2026 roku ten fundament nowoczesnej inżynierii oprogramowania został brutalnie podważony.
Ofiarą padła biblioteka litellm – kluczowe narzędzie w świecie AI, pobierane blisko 97 milionów razy miesięcznie. Złośliwe wersje (1.82.7 oraz 1.82.8) pojawiły się na PyPI z pominięciem standardowych procesów CI/CD – napastnicy wgrali je bezpośrednio, nie zostawiając żadnego śladu w postaci tagów czy wydań na GitHubie. Co gorsza, przez mechanizm zależności przechodnich zainfekowany kod trafiał do każdego systemu instalującego popularne pakiety takie jak dspy czy wtyczki MCP do edytora Cursor.
Jako architekci musimy sobie zadać pytanie: czy naprawdę wiemy, co dzieje się w naszym środowisku po naciśnięciu Enter?
Plik .pth – niewidzialna aktywacja bez jednej linii importu
Najbardziej przerażającym aspektem wersji 1.82.8 było wykorzystanie pliku litellm_init.pth. Deweloperzy żyją w przeświadczeniu, że złośliwy kod w bibliotece staje się groźny dopiero po instrukcji import. Ten atak udowodnił, że to błąd.
Pliki .pth (Path Configuration Files) są przetwarzane przez moduł site podczas inicjalizacji interpretera Pythona. Ich pierwotne przeznaczenie to dodawanie katalogów do sys.path, ale pozwalają na wykonanie dowolnego kodu za pomocą funkcji exec(). Dla napastnika to „Święty Graal" persystencji – złośliwy kod uruchamia się automatycznie przy każdym starcie interpretera, o ile plik znajduje się w site-packages.
"Złośliwy kod uruchamia się całkowicie automatycznie przy każdym uruchomieniu interpretera Pythona – nie jest do tego wymagane nawet importowanie biblioteki litellm."
Wystarczyło zainstalować pakiet, a malware aktywowało się przy uruchomieniu dowolnego, zupełnie niezwiązanego ze sprawą skryptu Pythona na danej maszynie. To całkowicie unieważnia doktrynę „jestem bezpieczny, bo nie używam tej biblioteki".
Dwie wersje, dwa podejścia – stealth kontra brute force
Warto zwrócić uwagę na dualność ataku, bo mówi ona wiele o metodologii napastników.
Wersja 1.82.7 była subtelna. Nie zawierała pliku .pth, lecz ukrywała payload wewnątrz proxy/proxy_server.py. Złośliwy kod aktywował się dopiero po uruchomieniu serwera proxy litellm – co oznacza, że celowano w środowiska produkcyjne, gdzie biblioteka faktycznie pracowała na co dzień. Cichy, chirurgicznie precyzyjny atak.
Wersja 1.82.8 postawiła na totalne przejęcie. Mechanizm .pth automatycznie infekował każde środowisko, w którym pakiet się znalazł – od laptopa dewelopera po serwer CI/CD. Ten dualizm sugeruje, że napastnik testował różne metody infekcji, iterując od cichej infiltracji po agresywną dominację.
Sprawdzanie tylko jednej wersji pakietu przy audycie może uśpić czujność zespołu SOC.
Bomba forkowa – gdy „vibe coding" hakera ratuje tysiące maszyn
To, że świat dowiedział się o ataku zaledwie godzinę po publikacji złośliwej paczki, zawdzięczamy wyłącznie niekompetencji napastników. Ich kod zawierał krytyczny błąd logiczny.
Mechanizm w pliku .pth wywoływał subprocess.Popen, aby uruchomić w tle proces kradzieży danych. Ponieważ każdy nowy proces Pythona ponownie ładował ten sam plik .pth, system wpadał w rekurencyjną pętlę tworzenia procesów – klasyczną bombę forkową. Zamiast cichej eksfiltracji danych, malware błyskawicznie pożerało całą dostępną pamięć RAM i zasoby procesora, doprowadzając do natychmiastowego crashu maszyny.
Callum McMahon z FutureSearch odkrył atak właśnie dlatego, że inżynierowie korzystający z Cursora i pluginów MCP (wciągających litellm) zaczęli zgłaszać masowe, niewyjaśnione zawieszenia systemów. Gdyby kod był napisany poprawnie, malware mogłoby rezydować w środowiskach tygodniami, po cichu drenując sekrety tysięcy firm. Ironia losu – to brak rzemiosła hakerów uratował całą społeczność.
„Odkurzacz" do poświadczeń – co dokładnie próbowali ukraść?
Analiza payloadu ujawnia przerażającą precyzję w doborze celów. Malware zostało zaprojektowane jako totalny „odkurzacz", który miał wyczyścić maszynę ze wszystkiego, co ma wartość w nowoczesnej infrastrukturze. Zebrane dane były pakowane do archiwum tpcp.tar.gz, szyfrowane AES-256-CBC (z kluczem sesyjnym zabezpieczonym 4096-bitowym RSA) i wysyłane w tle za pomocą curl.
Lista „zakupów" obejmowała:
- Fundamenty dostępu: Klucze SSH (id_rsa, ed25519), konfiguracje Git, historia powłoki (.bash_history, .zsh_history) oraz prywatne klucze SSL/TLS z /etc/ssl/private/ i certyfikaty Let's Encrypt.
- Infrastruktura Cloud i CI/CD: Pełne poświadczenia AWS (w tym tokeny IMDS), GCP (Application Default Credentials) i Azure. Szczególnie groźne: skanowanie w poszukiwaniu terraform.tfvars, .gitlab-ci.yml, Jenkinsfile i ansible.cfg.
- Kubernetes i kontenery: Konfiguracje klastrów (~/.kube/config), tokeny kont serwisowych oraz sekrety Dockera i Kaniko.
- Finanse i komunikacja: Portfele kryptowalut (od Bitcoina przez Ethereum i Solanę po Cardano) oraz adresy webhooków Slack/Discord wyciągnięte ze zmiennych środowiskowych (printenv).
Lateral Movement – ekspansja do klastrów Kubernetes
Atak nie kończył się na lokalnej maszynie. Malware posiadało logikę rozpoznawania środowiska Kubernetes – jeśli wykryło token serwisowy, próbowało odczytać sekrety klastra we wszystkich przestrzeniach nazw.
W celu zapewnienia sobie trwałości, malware próbowało tworzyć uprzywilejowane pody o nazwach node-setup-* w przestrzeni kube-system, używając obrazu alpine:latest. Pody te montowały system plików hosta, instalując backdoora w /root/.config/sysmon/sysmon.py. Nazwa sysmon nie była przypadkowa – miała sugerować legalne narzędzie do monitorowania systemu, co jest klasyczną techniką maskowania w środowiskach Linux.
Jeśli Twój klaster K8s miał jakikolwiek kontakt z zainfekowanym środowiskiem, traktuj go jako skompromitowany.
Pułapka domeny i sabotaż na GitHubie
Atak nie ograniczał się do kodu – był wspierany przez przemyślaną kampanię dezinformacyjną.
Dane były eksfiltrowane na domenę models.litellm.cloud. Dla zmęczonego inżyniera wygląda to na oficjalną infrastrukturę, podczas gdy legalna domena projektu to litellm.ai. Subtelna, ale skuteczna różnica.
Na GitHubie było jeszcze gorzej. Gdy użytkownicy otworzyli zgłoszenie #24512 alarmujące o malware, zostało ono nagle zamknięte jako „not planned" przez prawdopodobnie skompromitowane konto maintainera. Chwilę później dyskusję zalała fala setek botów publikujących generyczne komentarze w stylu „Thanks, that helped!" i „Great explanation!" – celowa operacja dezinformacyjna mająca na celu rozmycie ostrzeżeń pod stosem cyfrowego szumu i paraliż procesu reagowania na incydent.
To doskonały przykład nowoczesnej wojny informacyjnej prowadzonej wewnątrz społeczności Open Source.
Action Plan: Co musisz zrobić teraz
Jeśli w okolicach 24 marca 2026 r. w Twoim środowisku (lokalnym, CI/CD lub produkcyjnym) zainstalowano biblioteki AI, wykonaj te kroki:
- Weryfikacja wersji: pip show litellm. Jeśli widzisz 1.82.7 lub 1.82.8 – system jest zainfekowany.
- Głębokie czyszczenie cache: pip cache purge oraz krytycznie ważne: rm -rf ~/.cache/uv, jeśli korzystasz z narzędzia uv.
- Lokalizacja artefaktów: Wyszukaj plik litellm_init.pth w site-packages. Sprawdź obecność folderu ~/.config/sysmon/ oraz pliku sysmon.py.
- Audyt persystencji: Sprawdź, czy nie zarejestrowano nowej usługi systemd: ~/.config/systemd/user/sysmon.service.
- Kontrola klastrów K8s: W przestrzeni kube-system szukaj podów o nazwie node-setup-*. Jeśli tam są – klaster został przejęty na poziomie węzłów.
- ROTACJA TOTALNA: To najważniejszy krok. Jeśli znalazłeś jakiekolwiek ślady infekcji, wszystkie klucze SSH, poświadczenia chmurowe (AWS/GCP/Azure), tokeny API i hasła do baz danych należy uznać za skompromitowane i natychmiast zrotować. Samo usunięcie biblioteki nie cofnie faktu, że sekrety są już w posiadaniu napastnika.
Koniec ery bezgranicznego zaufania
Incydent z litellm to sygnał ostrzegawczy, którego nie wolno zignorować. W dobie szalonego wyścigu zbrojeń w AI, bezpieczeństwo łańcucha dostaw staje się naszą największą słabością. Tradycyjna architektura oparta na tysiącach „cegiełek" zależności to pole minowe – wystarczy, że jedna z dolnych cegieł w fundamencie jest zatruta, by cała konstrukcja stała się bronią wycelowaną w swojego twórcę.
Coraz częściej słuszną strategią architektoniczną staje się tzw. „yoinking" – zamiast dodawać kolejną ciężką zależność dla jednej funkcji, lepiej wykorzystać LLM do wygenerowania czystego, lokalnego kodu realizującego to samo zadanie. Zmniejszamy powierzchnię ataku i odzyskujemy kontrolę nad tym, co faktycznie wykonuje nasz interpreter.
Kiedy ostatni raz sprawdziłeś, co dokładnie instaluje Twoja następna zależność?
Aleksander
O autorze
Aleksander Zębrowski
Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Powiązane artykuły
Cyberbezpieczeństwo
Jak Zhakować Państwo Rozmawiając z Botem? Kulisy Kradzieży 150 GB Danych Rządu Meksyku
Sztuczna inteligencja miała ułatwiać nam życie, ale stała się też potężnym narzędziem w rękach cyberprzestępców. Poznaj kulisy fascynującego ataku, w którym haker użył modeli Claude i ChatGPT do ominięcia zabezpieczeń i kradzieży wrażliwych danych rządu Meksyku.
14:48 26.02.2026
10 min
Cyberbezpieczeństwo
WormGPT i KawaiiGPT: 5 faktów o mrocznej stronie AI
Sztuczna inteligencja to nie tylko medycyna i ułatwienia. To także wyspecjalizowane, złośliwe modele LLM, które demokratyzują cyberprzestępczość i tworzą idealne oszustwa.
20:21 22.12.2025
9 min
Cyberbezpieczeństwo
Jak Claude Code i autonomiczni agenci mogą włamać się do Twojej firmy?
Zapomnijcie o phishingu z błędami ortograficznymi. Rok 2025 przyniósł erę "agentycznej AI". Analizujemy, jak narzędzia deweloperskie takie jak Claude Code stały się bronią w rękach grup APT i dlaczego "Vibe Hacking" to termin, który musicie znać.
06.12.2025
13 min
Komentarze
Ładowanie komentarzy...