Wprowadzenie do problemu / definicja
MLflow to popularna platforma open source używana do zarządzania cyklem życia modeli uczenia maszynowego, w tym eksperymentami, rejestrem modeli oraz procesami wdrożeniowymi. Najnowsze doniesienia wskazują, że atakujący aktywnie wykorzystują krytyczną podatność typu SSRF w MLflow, aby wymuszać żądania HTTP z poziomu podatnego serwera do wewnętrznych zasobów sieciowych.
W praktyce oznacza to możliwość sięgania do usług metadanych chmurowych, a następnie pozyskania tokenów, kluczy dostępowych i innych sekretów. To szczególnie groźny scenariusz w środowiskach MLOps, gdzie jedna usługa często ma szeroki dostęp do magazynów danych, artefaktów i komponentów automatyzacji.
W skrócie
- Podatność została oznaczona jako CVE-2026-64849.
- Problem dotyczy wersji MLflow wcześniejszych niż 3.15.0.
- Luka umożliwia nieautoryzowany atak SSRF.
- Atakujący mogą próbować pozyskać poświadczenia chmurowe i sekrety z hosta, na którym działa MLflow.
- Zagrożone są szczególnie instancje wystawione do internetu i uruchomione w środowiskach chmurowych.
Kontekst / historia
SSRF od lat należy do najgroźniejszych klas podatności w aplikacjach webowych i backendowych. W środowiskach chmurowych jej znaczenie dodatkowo rośnie, ponieważ podatna aplikacja może uzyskać dostęp do lokalnych usług administracyjnych, które normalnie nie są osiągalne z internetu.
W przypadku MLflow wektor ataku wiązany jest z mechanizmem webhooków rejestru modeli. Tego rodzaju funkcjonalność, jeśli nie jest odpowiednio zabezpieczona, może zostać nadużyta do kierowania żądań do arbitralnych adresów, w tym do zasobów wewnętrznych. Publiczne obserwacje sugerują, że aktywność atakujących pojawiła się bardzo szybko po ujawnieniu podatności, co wpisuje się w szerszy trend błyskawicznego wykorzystywania nowych luk w popularnych projektach open source.
Analiza techniczna
CVE-2026-64849 to nieautoryzowana podatność SSRF o wysokiej krytyczności. Napastnik, który może komunikować się z serwerem śledzenia MLflow, jest w stanie skłonić podatną instancję do wysyłania żądań HTTP do wskazanych lokalizacji wewnętrznych. Szczególnie niebezpieczne są tutaj usługi metadanych chmurowych, zwykle dostępne tylko lokalnie z poziomu maszyny wirtualnej lub kontenera.
Typowy scenariusz ataku może obejmować identyfikację publicznie dostępnej instancji MLflow, nadużycie funkcji powiązanej z webhookami rejestru modeli, wymuszenie połączenia do wewnętrznego adresu IP lub endpointu metadanych, a następnie odczyt odpowiedzi zawierającej tokeny tymczasowe, klucze API albo inne dane uwierzytelniające.
Istotnym elementem tej sprawy jest to, że wada miała omijać wcześniejsze zabezpieczenia ze względu na sposób obsługi przekierowań HTTP. To sugeruje, że częściowe filtrowanie adresów docelowych lub uproszczone kontrole logiki żądań nie wystarczały do zamknięcia całego wektora nadużycia. W praktyce atakujący często wykorzystują w takich sytuacjach przekierowania, alternatywne reprezentacje adresów IP, rozbieżności w parsowaniu adresów URL oraz nazwy hostów rozwiązywane do adresów wewnętrznych.
Z perspektywy obrony trzeba podkreślić, że skutki SSRF w środowiskach AI i MLOps rzadko kończą się na samym wycieku metadanych. Serwer MLflow bywa połączony z repozytoriami artefaktów, magazynami obiektowymi, bazami danych oraz narzędziami CI/CD. To sprawia, że pojedyncza luka aplikacyjna może stać się punktem wejścia do znacznie szerszej kompromitacji środowiska.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest przejęcie poświadczeń chmurowych i sekretów aplikacyjnych. Jeśli MLflow działa z nadmiernymi uprawnieniami lub ma dostęp do wrażliwych zasobów, skutki incydentu mogą być daleko idące.
- Dostęp do bucketów i magazynów obiektowych z modelami oraz danymi treningowymi.
- Odczyt lub modyfikacja artefaktów uczenia maszynowego.
- Kradzież sekretów używanych przez pipeline’y MLOps.
- Wykonywanie dalszych działań w infrastrukturze chmurowej przy użyciu przejętych tożsamości.
- Trwałe osadzenie się atakującego w środowisku i dalszy ruch boczny.
Ryzyko jest szczególnie wysokie tam, gdzie MLflow pozostaje publicznie dostępny, ruch wychodzący z serwera nie jest ograniczany, a role chmurowe mają zbyt szerokie uprawnienia. Dodatkowym problemem pozostaje możliwość cichej eksfiltracji danych, która nie zawsze generuje oczywiste ślady, jeśli organizacja nie monitoruje połączeń do usług metadanych i nietypowych żądań HTTP inicjowanych przez aplikację.
Rekomendacje
Priorytetem powinno być jak najszybsze zaktualizowanie MLflow do wersji 3.15.0 lub nowszej wszędzie tam, gdzie nadal działają podatne wydania. Jeżeli natychmiastowa aktualizacja nie jest możliwa, organizacje powinny wdrożyć środki kompensacyjne ograniczające powierzchnię ataku.
- Odciąć publiczny dostęp do serwerów MLflow, jeśli nie jest bezwzględnie potrzebny.
- Niezwłocznie wdrożyć poprawkę eliminującą CVE-2026-64849.
- Przeanalizować logi aplikacyjne, reverse proxy, WAF i telemetry sieciowe pod kątem prób połączeń do adresów lokalnych i endpointów metadanych.
- Sprawdzić, czy z instancji MLflow wykonywano połączenia do usług metadanych chmurowych.
- Zrotować wszystkie poświadczenia, tokeny i sekrety, które mogły być dostępne z poziomu podatnego hosta.
- Zrewidować uprawnienia ról przypisanych do maszyn, kontenerów i workloadów obsługujących MLflow.
- Ograniczyć ruch wychodzący do niepotrzebnych zakresów adresowych i lokalnych endpointów administracyjnych.
- Zastosować listy dozwolonych adresów docelowych dla webhooków lub tymczasowo wyłączyć tę funkcję.
- Wdrożyć segmentację sieci oraz kontrolę egress na poziomie hosta, klastra lub sieci chmurowej.
- Objąć środowiska MLOps monitoringiem nastawionym na wykrywanie nadużyć SSRF i anomalii w dostępie do zasobów wewnętrznych.
Z perspektywy architektury bezpieczeństwa warto również traktować platformy AI i MLOps jako systemy uprzywilejowane. Nawet jeśli nie pełnią klasycznej roli administracyjnej, ich integracja z wieloma zasobami zaplecza oznacza wysoki potencjalny wpływ incydentu.
Podsumowanie
Aktywne wykorzystywanie CVE-2026-64849 pokazuje, że środowiska AI i MLOps stały się atrakcyjnym celem ataków wymierzonych w infrastrukturę chmurową. Luka SSRF w MLflow może umożliwić przejęcie poświadczeń oraz sekretów z wewnętrznych usług metadanych, a następnie otworzyć drogę do dalszej kompromitacji środowiska.
Dla organizacji korzystających z MLflow to problem o wysokim priorytecie operacyjnym. Kluczowe działania obejmują szybkie wdrożenie poprawek, weryfikację ekspozycji usługi, analizę śladów potencjalnego wykorzystania oraz rotację wszystkich danych uwierzytelniających, które mogły zostać ujawnione.