CVE-2026-64849

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.

W MLflow występuje podatność polegająca na słabych wymaganiach dotyczących haseł, umożliwiająca obejście uwierzytelniania. Atakujący nie musi się uwierzytelniać; problem wynika ze słabych wymagań dotyczących haseł i może zostać wykorzystany do obejścia uwierzytelniania w systemie.

MLflow to otwarta platforma inżynierii AI dla agentów, dużych modeli językowych i modeli uczenia maszynowego. Od wersji 2.19.0 do 3.17.0 mlflow.crewai.autolog() rejestruje obiekty CrewAI Agent bez konsekwentnej sanityzacji zagnieżdżonych wartości zawierających poświadczenia. mlflow/crewai/autolog.py::_get_agent_attributes() konwertuje pole Agent llm na ciąg znaków zawierający klucz API dostawcy, podczas gdy mlflow/crewai/autolog.py::_construct_full_inputs() rozwija obiekt Agent do mlflow.spanInputs. Aplikacje mogą zatem wysyłać jawne poświadczenia dostawcy do backendu śledzenia MLflow lub skonfigurowanego miejsca docelowego OTLP, gdzie czytelnicy śladów mogą je uzyskać. Problem został naprawiony w wersji 3.17.0.