Wprowadzenie do problemu / definicja
MLflow to popularna platforma open source wykorzystywana do śledzenia eksperymentów, rejestrowania modeli oraz zarządzania cyklem życia rozwiązań uczenia maszynowego. Ujawniona podatność CVE-2026-64849 pokazuje jednak, że narzędzia MLOps mogą stać się atrakcyjnym wektorem ataku, zwłaszcza gdy są połączone z infrastrukturą chmurową i przechowują dostęp do wrażliwych zasobów.
Problem dotyczy luki typu Server-Side Request Forgery, czyli SSRF. Tego rodzaju błąd pozwala atakującemu zmusić podatny serwer do wykonywania żądań HTTP do wskazanych adresów, także takich, które z zewnątrz nie są bezpośrednio dostępne. W praktyce może to prowadzić do odczytu danych z sieci wewnętrznej, usług administracyjnych oraz endpointów metadanych dostawców chmury.
W skrócie
CVE-2026-64849 to krytyczna, nieuwierzytelniona luka SSRF w MLflow, oceniona na 9.3 w skali CVSS. Podatność dotyczy wersji wcześniejszych niż 3.15.0 i może zostać wykorzystana do odpytywania zasobów wewnętrznych oraz pozyskiwania sekretów i tymczasowych poświadczeń chmurowych.
- podatność nie wymaga uwierzytelnienia, jeśli instancja jest wystawiona i osiągalna,
- wektor ataku wiąże się z obsługą webhooków rejestru modeli,
- atak może omijać wcześniejsze mechanizmy ochronne dzięki przekierowaniom HTTP,
- zagrożone są szczególnie publicznie dostępne serwery MLflow z szerokimi uprawnieniami.
Kontekst / historia
MLflow od lat jest jednym z najczęściej wykorzystywanych narzędzi w ekosystemie MLOps. Platforma pełni istotną rolę w organizacjach rozwijających modele AI, ponieważ łączy proces eksperymentowania, zarządzania artefaktami oraz rejestracji modeli w jednym środowisku. Z tego powodu kompromitacja takiego systemu może mieć znacznie szersze skutki niż incydent dotyczący zwykłej aplikacji webowej.
W ostatnich latach rosło zainteresowanie bezpieczeństwem narzędzi AI i platform wspierających proces trenowania oraz wdrażania modeli. Wynika to z ich uprzywilejowanego położenia w architekturze: często mają dostęp do magazynów danych, systemów CI/CD, rejestrów kontenerów, obiektowych repozytoriów artefaktów oraz usług chmurowych. Właśnie dlatego luka SSRF w takim środowisku może stać się punktem wyjścia do szerszej kompromitacji infrastruktury.
Analiza techniczna
Istota błędu sprowadza się do możliwości wykorzystania serwera MLflow jako pośrednika do wysyłania żądań HTTP do arbitralnych lokalizacji. Atakujący może wskazać cel w postaci zasobu lokalnego, adresu prywatnego albo endpointu metadanych działającego w chmurze. Jeśli instancja MLflow pracuje na hoście z przypisaną rolą lub tożsamością uprzywilejowaną, skutkiem może być wyciek tokenów, kluczy tymczasowych lub innych danych umożliwiających dalszy dostęp.
Z dostępnych informacji wynika, że podatność jest związana z mechanizmem webhooków w rejestrze modeli. Szczególnie istotny jest fakt, że exploit może wykorzystywać obsługę przekierowań HTTP, co pozwala omijać niektóre wcześniejsze zabezpieczenia oparte wyłącznie na walidacji początkowego adresu docelowego. To klasyczny problem w obronie przed SSRF: nawet jeśli pierwszy adres wygląda bezpiecznie, dalszy łańcuch przekierowań może prowadzić do usługi wewnętrznej.
Warunkiem skutecznego ataku jest możliwość dotarcia do podatnej instancji. Najbardziej narażone są środowiska testowe, badawcze i hybrydowe, gdzie serwery MLflow bywają publikowane szybciej i z mniejszą kontrolą bezpieczeństwa niż systemy produkcyjne. Brak segmentacji, niewłaściwa konfiguracja reverse proxy oraz brak uwierzytelniania przed interfejsem aplikacji dodatkowo zwiększają ryzyko.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem wykorzystania CVE-2026-64849 jest kradzież poświadczeń chmurowych i sekretów. Przejęte tokeny mogą umożliwić przegląd zasobów, odczyt danych z magazynów obiektowych, dostęp do baz danych lub wykorzystanie uprawnień do dalszego ruchu bocznego w środowisku.
Ryzyko nie kończy się jednak na samym wycieku danych. W środowisku MLOps atakujący może próbować wpłynąć na integralność procesu trenowania i wdrażania modeli. Oznacza to możliwość manipulacji artefaktami, metadanymi eksperymentów, a nawet podmiany modeli lub ingerencji w pipeline’y wdrożeniowe. Taki scenariusz stanowi zagrożenie nie tylko dla poufności, ale również dla jakości i wiarygodności wyników systemów AI.
- wyciek tymczasowych poświadczeń i tokenów dostępowych,
- dostęp do wewnętrznych usług i zasobów chmurowych,
- naruszenie integralności artefaktów modeli i metadanych,
- ryzyko długotrwałej, trudnej do wykrycia obecności w środowisku,
- problemy zgodności, audytu i odtwarzalności procesów ML.
Rekomendacje
Najważniejszym krokiem powinno być niezwłoczne zaktualizowanie MLflow do wersji 3.15.0 lub nowszej. Organizacje, które nie mogą wdrożyć poprawki natychmiast, powinny tymczasowo ograniczyć dostęp do instancji wyłącznie do zaufanych sieci, usunąć ekspozycję internetową i wymusić uwierzytelnianie przed dostępem do interfejsu.
Warto również potraktować incydent szerzej niż standardową aktualizację aplikacji. Jeżeli istnieje podejrzenie, że podatna instancja była dostępna publicznie, konieczna może być analiza logów, ocena wpływu na tożsamości maszynowe oraz rotacja poświadczeń i sekretów.
- zidentyfikować wszystkie publicznie dostępne instancje MLflow,
- przeanalizować logi aplikacyjne, reverse proxy i zapór pod kątem nietypowych żądań,
- zablokować ruch wychodzący do endpointów metadanych i nieautoryzowanych adresów wewnętrznych,
- zweryfikować uprawnienia IAM hostów uruchamiających MLflow,
- przeprowadzić rotację tokenów, kluczy i sekretów powiązanych z narażonymi systemami,
- wdrożyć segmentację środowisk MLOps i kontrolę integracji wychodzących.
Podsumowanie
CVE-2026-64849 potwierdza, że platformy MLOps powinny być traktowane jak element krytycznej powierzchni ataku. Luka SSRF w MLflow może prowadzić nie tylko do odczytu wewnętrznych zasobów, ale również do przejęcia poświadczeń chmurowych i dalszej kompromitacji środowiska.
Dla zespołów bezpieczeństwa oznacza to potrzebę szybkiego łatania, ograniczania ekspozycji sieciowej oraz prowadzenia pełnej analizy po incydencie. Samo usunięcie błędu może nie wystarczyć, jeśli wcześniej doszło już do wycieku sekretów lub nadużycia uprawnień. W przypadku systemów AI równie ważna jak dostępność jest bowiem integralność całego procesu tworzenia i wdrażania modeli.
Źródła
- Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secrets — https://thehackernews.com/2026/08/attackers-exploit-mlflow-ssrf-flaw-to.html
- MLflow Security Advisories — https://github.com/mlflow/mlflow/security
- MLflow CHANGELOG — https://github.com/mlflow/mlflow/blob/master/CHANGELOG.md
- MLflow Self-Hosting Architecture: Artifact Store — https://github.com/mlflow/mlflow/blob/master/docs/docs/self-hosting/architecture/artifact-store.mdx
- [SETUP-BUG] Delay CVE disclosure until fix is available — https://github.com/mlflow/mlflow/issues/23364