TL;DR

Od kwietnia do lipca 2026 opisaliśmy na cyberowi.pl kilkanaście podatności w narzędziach AI/ML. Ten przegląd konsoliduje siedem najważniejszych z drugiego kwartału i wyciąga z nich wzorce, które nie znikną wraz z kolejną łatką:

  • Luki w samych narzędziach: MLflow (XSS + brak autoryzacji, wszystkie wersje do 3.10.1), Ollama na Windows (RCE przez proces aktualizacji, wersje 0.12.10–0.17.5), ModelScope (RCE przez spreparowany plik konfiguracyjny modelu), MCPHub (obejście uwierzytelniania poniżej 0.11.0), OpenClaw (łańcuch czterech luk pozwalający przejąć serwery agentów AI).
  • Ataki na łańcuch dostaw: zatrute wersje 2.6.2 i 2.6.3 PyTorch Lightning na PyPI kradły poświadczenia; złośliwa wersja 0.10.1 pakietu guardrails-ai (CVE-2026-45758, CVSS 9.6) wykonywała kod już przy instalacji.
  • Wspólny mianownik: narzędzia AI/ML trafiają do firm bokiem — instalowane przez zespoły data science poza standardowym procesem IT — i przez to wypadają z radaru aktualizacji i audytów.

Jeśli Twój zespół używa któregokolwiek z opisanych narzędzi, w sekcji „Co zrobić” znajdziesz minimalny plan działań. Każdy incydent ma też osobny, szczegółowy alert — linki w tekście.

Dlaczego narzędzia AI stały się celem

Ekosystem narzędzi AI/ML dojrzewał szybciej, niż dojrzewały jego praktyki bezpieczeństwa. Serwery eksperymentów, lokalne runtime’y modeli i frameworki agentowe są często wystawiane do sieci bez uwierzytelniania, bo „to tylko wewnętrzne narzędzie zespołu”. Jednocześnie stacja robocza inżyniera ML przechowuje zwykle klucze do chmury, tokeny repozytoriów i dostęp do danych treningowych — czyli dokładnie to, czego szuka atakujący.

Drugi kwartał 2026 pokazał, że przestępcy zauważyli tę dysproporcję. Poniżej wszystkie incydenty, które opisaliśmy — pogrupowane według wektora.

Wzorzec 1: luki w narzędziach, które hostujesz

MLflow — XSS i brak autoryzacji (do wersji 3.10.1). CERT Polska opublikował w kwietniu alert o dwóch podatnościach w popularnym frameworku do zarządzania eksperymentami ML. CVE-2026-33865 to Stored XSS w parsowaniu plików YAML, a CVE-2026-33866 — brak autoryzacji w endpoincie AJAX. Skutki: przejęcie sesji, kradzież modeli, wykonywanie operacji w imieniu użytkownika. Szczegóły w alercie: MLflow: dwie krytyczne luki w parsowaniu modeli.

Ollama na Windows — RCE przez aktualizator (0.12.10–0.17.5). Pod koniec kwietnia CERT Polska ujawnił dwie luki w Ollama, narzędziu do lokalnego uruchamiania modeli. Obie umożliwiają zdalne wykonanie kodu przez zainfekowanie procesu aktualizacji. Analiza: Ollama na Windows: dwie krytyczne luki w aktualizacjach.

ModelScope — RCE przez plik konfiguracyjny modelu (1.25.0). CVE-2025-51427 pozwala wykonać kod przez załadowanie modelu ze spreparowanym plikiem dey_mini.yaml. To praktyczna lekcja: pobranie otwartego modelu z publicznego repozytorium jest operacją tak samo ryzykowną jak instalacja nieznanego pakietu. Więcej: RCE w ModelScope — zagrożenie dla projektów AI.

MCPHub — obejście uwierzytelniania (poniżej 0.11.0). Brak ochrony na części endpointów pozwalał wykonywać operacje z uprawnieniami innych użytkowników bez logowania. Dla instancji dostępnych z internetu to scenariusz „każdy może działać jako każdy”. Alert: MCPHub: obejście uwierzytelniania grozi przejęciem kont.

OpenClaw — łańcuch czterech luk. W maju ujawniono łańcuch podatności w platformie agentowej OpenClaw, pozwalający na przejęcie kontroli nad serwerem. Publicznie dostępne instancje zwiększały ryzyko wykorzystania tych błędów. Analiza: Claw Chain: 4 luki w OpenClaw.

Wzorzec 2: zatruty łańcuch dostaw PyPI

PyTorch Lightning 2.6.3 — kradzież poświadczeń. Złośliwa wersja popularnego frameworka trafiła do oficjalnego repozytorium PyPI i po import lightning uruchamiała ukryty łańcuch wykonania pobierający złośliwy kod. Atak ujawniono 30 kwietnia; bezpieczna pozostała wersja 2.6.1. Kto uruchomił 2.6.2 lub 2.6.3, powinien założyć kompromitację sekretów. Szczegóły: PyTorch Lightning na PyPI zainfekowany kradzieżą poświadczeń.

guardrails-ai 0.10.1 — RCE przy instalacji (CVE-2026-45758, CVSS 9.6). 11 maja w PyPI pojawiła się złośliwa wersja frameworka do budowy aplikacji AI. Kod wykonywał się już podczas pip install, a celem były tokeny GitHub, klucze chmurowe i inne klucze API — najbardziej narażone były systemy CI/CD. Analiza: Krytyczna luka w guardrails-ai.

Wzorzec się nie zatrzymał: w czerwcu i lipcu opisaliśmy kolejne luki w Crawl4AI, NLTK, picklescan i Snowflake CLI.

Kontekst dla polskich zespołów

W polskich firmach narzędzia AI/ML najczęściej wprowadza nie dział IT, lecz pojedynczy zespół — data science, analitycy, czasem marketing. To oznacza, że MLflow czy Ollama rzadko figurują w firmowym rejestrze oprogramowania i nie obejmuje ich standardowy proces łatania. Trzy konsekwencje praktyczne:

  1. Inwentaryzacja jest pierwszym problemem, nie łatanie. Nie zaktualizujesz narzędzia, o którym nie wiesz, że działa w Twojej sieci.
  2. Stacja inżyniera ML to konto uprzywilejowane. Klucze do chmury i tokeny repozytoriów na jednej maszynie oznaczają, że kompromitacja jednego laptopa może otworzyć całą infrastrukturę. Wyciek danych osobowych z takiego dostępu podlega zgłoszeniu do Prezesa UODO zgodnie z RODO.
  3. Organizacje objęte NIS2 powinny traktować zależności Pythona jak każdy inny element łańcucha dostaw — z audytem i dokumentacją.

Co zrobić

Rekomendowane podejście — nie zastępuje pełnego audytu, ale porządkuje pierwsze kroki:

  1. Zinwentaryzuj narzędzia AI/ML działające w firmie (serwery MLflow, lokalne instancje Ollama, frameworki agentowe) i sprawdź wersje względem tabeli powyżej.
  2. Odetnij od internetu wszystko, co nie musi być publiczne. Większość opisanych ataków wymaga dostępu sieciowego do usługi.
  3. Przypnij wersje zależności (pip freeze, lockfile) i rozważ narzędzia typu pip-audit w CI/CD. Pomagają wykrywać zależności powiązane z opublikowanymi podatnościami, ale nie gwarantują wykrycia świeżego złośliwego wydania.
  4. Traktuj pobierane modele jak kod. Przypadek ModelScope pokazuje, że plik konfiguracyjny modelu może wykonać kod na Twojej maszynie.
  5. Po podejrzeniu instalacji zatrutego pakietu — rotacja wszystkich poświadczeń z zainfekowanej maszyny, nie tylko tych „używanych w projekcie”.

Źródła

  1. cert.pl › CVE 2026 33865
  2. cert.pl › CVE 2026 42248
  3. nvd.nist.gov › CVE 2026 45758
  4. nvd.nist.gov › CVE 2025 51427
  5. thehackernews.com › pytorch lightning compromised in pypi
  6. thehackernews.com › four openclaw flaws enable data theft

Zobacz też

Zobacz też