CVE-2026-116691

MLflow to otwarta platforma inżynierii AI dla agentów, dużych modeli językowych i modeli uczenia maszynowego. Od wersji 3.10.0 do 3.17.0 gałąź prompt w _create_model_version() akceptuje względne źródła bez schematu, ponieważ walidacja ścieżki jest uruchamiana tylko wtedy, gdy źródło ma schemat URL, a mlflow.prompt.is_prompt jest interpretowane przez obecność tagu, a nie przez prawdziwą wartość. Zdalny wywołujący może zapisać lokalną ścieżkę serwera jako lokalizację artefaktu wersji modelu i użyć /api/2.0/mlflow/model-versions/get-artifact do odczytu plików dostępnych dla procesu serwera MLflow. Domyślne nieuwierzytelnione serwery nie wymagają uprawnień, podczas gdy wdrożenia z podstawowym uwierzytelnianiem są narażone na użytkowników uwierzytelnionych, którzy mogą tworzyć zarejestrowane modele. Problem został naprawiony w wersji 3.17.0.

W wersjach MLflow przed 3.9.0 występuje podatność typu Server-Side Request Forgery (SSRF). Funkcja `_create_webhook()` akceptuje parametr `url` kontrolowany przez użytkownika bez walidacji, co pozwala atakującemu na wymuszenie wysyłania żądań HTTP do wewnętrznych usług lub zewnętrznych serwerów.

W MLflow w wersjach od 3.12.0rc0 do 3.17.0 deserializacja scorerów zewnętrznych w mlflow/genai/scorers/base.py akceptuje klasy potomne modułów z listy dozwolonych zamiast wymagać dokładnie dozwolonego modułu. Atakujący może umieścić moduł Pythona w zapisywalnym pakiecie dozwolonym i wywołać go przez endpoint /ajax-api/3.0/mlflow/scorer/invoke, co prowadzi do wykonania kodu. Wersja 3.17.0 naprawia problem.

Podatność w MLflow w wersjach do 3.10.1.dev0 umożliwia nieautoryzowany dostęp do endpointów przesyłania wieloczęściowego (MPU) przy włączonym trybie `--serve-artifacts`. Logika autoryzacji nie wymusza sprawdzania uprawnień na poziomie zasobów dla endpointów `/mlflow-artifacts/mpu/*`, co pozwala atakującym nadpisywać artefakty innych użytkowników. Może to prowadzić do nieautoryzowanego zapisu między użytkownikami, zatrucia łańcucha dostaw modeli oraz zdalnego wykonania kodu po załadowaniu skompromitowanych modeli.

W MLflow w wersji 3.9.0 funkcja Asystenta MLflow zawiera podatność polegającą na nieprawidłowej walidacji pochodzenia żądań w punktach końcowych /ajax-api. Umożliwia to zdalnemu atakującemu wykorzystanie żądań międzyoriginowych ze złośliwej strony internetowej do interakcji z Asystentem MLflow działającym na lokalnym komputerze ofiary.

W mlflow/mlflow endpointy FastAPI dla zadań pod `/ajax-api/3.0/jobs/*` nie są chronione uwierzytelnianiem ani autoryzacją, gdy włączona jest aplikacja `basic-auth`. Nawet jeśli włączono uwierzytelnianie podstawowe, każdy klient sieciowy może bez poświadczeń przesyłać, odczytywać, wyszukiwać i anulować zadania.

W MLflow w wersji 3.8.0 wykryto podatność na wstrzykiwanie poleceń w kodzie inicjalizującym kontener serwowania modeli. Funkcja `_install_model_dependencies_to_env()` bezpośrednio interpoluje zależności z pliku `python_env.yaml` do polecenia powłoki bez sanityzacji, co umożliwia atakującemu wykonanie dowolnych poleceń poprzez dostarczenie złośliwego artefaktu modelu.

W bibliotece mlflow przed wersją 3.7.0 wykryto podatność na ścieżkę przejścia (path traversal) w funkcji `extract_archive_to_dir`. Brak walidacji ścieżek wewnątrz archiwum tar pozwala atakującemu na nadpisanie dowolnych plików lub eskalację uprawnień.

Podatność w procesie ekstrakcji pyfunc w MLflow umożliwia zapis dowolnych plików z powodu nieprawidłowego obsługiwania wpisów archiwum tar. Użycie `tarfile.extractall` bez walidacji ścieżki pozwala spreparowanym plikom tar.gz zawierającym `..` lub ścieżki absolutne na opuszczenie docelowego katalogu ekstrakcji.