Wprowadzenie do problemu / definicja
MLflow, popularna platforma open source wykorzystywana do zarządzania cyklem życia modeli uczenia maszynowego, znalazła się w centrum poważnego incydentu bezpieczeństwa. Chodzi o krytyczną podatność typu SSRF, która pozwala napastnikowi wymuszać żądania HTTP z poziomu serwera MLflow do zasobów wewnętrznych, w tym usług metadanych środowisk chmurowych.
W praktyce oznacza to, że błędnie wystawiony serwer MLflow może stać się pomostem do pozyskania wrażliwych danych, takich jak tokeny tymczasowe, sekrety aplikacyjne czy poświadczenia dostępu do usług chmurowych. To szczególnie niebezpieczne w środowiskach MLOps, gdzie jedna instancja często komunikuje się z wieloma krytycznymi komponentami infrastruktury.
W skrócie
Podatność oznaczono jako CVE-2026-64849, a jej ocena CVSS 9.3 wskazuje na bardzo wysoki poziom ryzyka. Problem dotyczy domyślnej konfiguracji MLflow Tracking Server, w której interfejs webhooków rejestru modeli może być dostępny bez odpowiedniego uwierzytelniania.
- atak umożliwia realizację SSRF z poziomu serwera MLflow,
- celem mogą być usługi metadanych chmurowych i inne zasoby wewnętrzne,
- zagrożone są wersje MLflow wcześniejsze niż 3.15.0,
- podatność była wykorzystywana aktywnie krótko po ujawnieniu.
Kontekst / historia
MLflow od lat jest jednym z kluczowych narzędzi wykorzystywanych w projektach związanych z MLOps. Służy do śledzenia eksperymentów, rejestrowania modeli, zarządzania artefaktami oraz wspierania wdrożeń w środowiskach produkcyjnych. Wraz ze wzrostem znaczenia rozwiązań AI rośnie także atrakcyjność takich platform dla cyberprzestępców.
W tym przypadku źródłem problemu okazała się architektura serwera śledzącego i możliwość ekspozycji API webhooków bez skutecznej kontroli dostępu. Dodatkowo wcześniejsze mechanizmy ograniczające SSRF nie zapewniły pełnej ochrony, ponieważ logika aplikacji nadal mogła zwracać odpowiedzi z odpytywanych zasobów wewnętrznych. To pokazuje, że częściowe zabezpieczenia są niewystarczające, jeśli podstawowy model zaufania pozostaje błędny.
Analiza techniczna
Istota podatności sprowadza się do nieautoryzowanego SSRF w MLflow Tracking Server. Atakujący może inicjować żądania do określonych endpointów aplikacji, a następnie skłonić serwer do nawiązania połączenia z wybranym adresem HTTP. Jeżeli serwer ma dostęp do sieci wewnętrznej lub usług dostawcy chmury, otwiera to drogę do pozyskania danych, które nie powinny być dostępne z Internetu.
Najgroźniejszy scenariusz dotyczy środowisk chmurowych. W takich wdrożeniach serwer MLflow może mieć dostęp do endpointów metadanych, z których da się pobrać informacje o instancji, tokeny sesyjne, dane kont serwisowych lub inne sekrety związane z tożsamością maszyny. Jeżeli aplikacja zwraca treść odpowiedzi do atakującego, luka przestaje być wyłącznie problemem sieciowym i staje się bezpośrednim narzędziem eksfiltracji danych.
Technicznie podatność łączy trzy niebezpieczne cechy:
- brak wymaganego uwierzytelniania dla wrażliwego API,
- możliwość generowania żądań do arbitralnych adresów,
- zwracanie odpowiedzi z zasobów wewnętrznych do inicjującego żądanie.
W efekcie publicznie dostępna instancja MLflow może zostać użyta jako pośrednik do komunikacji z systemami, które normalnie pozostają odseparowane od sieci zewnętrznej. W środowiskach MLOps konsekwencje są szczególnie poważne, ponieważ host MLflow bywa zintegrowany z magazynami obiektów, bazami danych, pipeline’ami CI/CD, rejestrami modeli i usługami inferencyjnymi.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem wykorzystania luki jest przejęcie poświadczeń chmurowych i dalsze poruszanie się po infrastrukturze organizacji. Kradzież tokenów tymczasowych może umożliwić dostęp do danych, zmianę konfiguracji usług oraz rozwinięcie ataku na kolejne systemy.
- odczyt lub modyfikacja danych w magazynach obiektowych,
- dostęp do rejestrów modeli, artefaktów i danych treningowych,
- eskalacja uprawnień w środowisku chmurowym,
- ruch lateralny między usługami i komponentami MLOps,
- eksfiltracja sekretów aplikacyjnych i informacji operacyjnych.
Ryzyko nie ogranicza się do samego MLflow. Kompromitacja tej warstwy może prowadzić do manipulacji pipeline’ami danych, podmiany modeli, zatrucia procesów wdrożeniowych oraz naruszenia integralności wyników generowanych przez systemy AI. Dla organizacji oznacza to zagrożenia operacyjne, finansowe, regulacyjne i reputacyjne.
Rekomendacje
Organizacje korzystające z MLflow powinny potraktować tę podatność priorytetowo. Pierwszym krokiem powinno być szybkie ustalenie, które instancje są publicznie dostępne oraz czy działają w podatnych wersjach oprogramowania. Sama aktualizacja jest konieczna, ale nie powinna być jedynym działaniem obronnym.
- zaktualizować MLflow do wersji 3.15.0 lub nowszej,
- usunąć publiczną ekspozycję serwera lub umieścić go za warstwą uwierzytelniania,
- ograniczyć lub zablokować dostęp do usług metadanych chmurowych, jeśli nie jest niezbędny,
- wdrożyć filtrowanie ruchu wychodzącego, zwłaszcza do adresów wewnętrznych i wrażliwych endpointów,
- przeanalizować logi aplikacyjne, sieciowe i chmurowe pod kątem nietypowych żądań HTTP,
- przeprowadzić rotację poświadczeń i sekretów w przypadku podejrzenia ujawnienia,
- zweryfikować uprawnienia ról przypisanych instancjom zgodnie z zasadą najmniejszych uprawnień,
- objąć webhooki i nietypowe wywołania API dodatkowymi regułami monitoringu.
Z perspektywy bezpieczeństwa architektury warto traktować platformy AI i MLOps tak samo jak inne systemy krytyczne dla biznesu. Oznacza to konieczność segmentacji sieci, silnego IAM, pełnego uwierzytelniania interfejsów administracyjnych oraz regularnych przeglądów powierzchni ataku.
Podsumowanie
CVE-2026-64849 to przykład podatności, która z pozoru dotyczy pojedynczego mechanizmu aplikacyjnego, ale w praktyce może prowadzić do przejęcia zasobów chmurowych i dalszej kompromitacji całego środowiska. Dla zespołów bezpieczeństwa, DevOps i DevSecOps kluczowe jest szybkie wdrożenie poprawek, ograniczenie ekspozycji MLflow oraz sprawdzenie, czy infrastruktura nie została już wykorzystana przez napastników.
Źródła
- SecurityWeek – MLflow Vulnerability Exploited for Cloud Credential Theft
https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/ - CVE Record – CVE-2026-64849
https://www.cve.org/CVERecord?id=CVE-2026-64849 - MLflow Security Advisories
https://github.com/mlflow/mlflow/security - CISA Known Exploited Vulnerabilities Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog