MLflow CVE-2026-64849, 69146 i 69148: webhook, lineage i artefakty przekraczają granice

17 sierpnia 2026 roku opublikowano trzy rekordy CVE dotyczące MLflow. CVE-2026-64849 opisuje nieuwierzytelniony SSRF w testowaniu webhooków, który potrafił ominąć walidację przez przekierowanie HTTP lub ponowne rozwiązanie DNS. CVE-2026-69146 pozwalało zalogowanemu użytkownikowi dopisać metadane dataset lineage do cudzego runu bez uprawnienia UPDATE. CVE-2026-69148 umożliwiało utworzenie wersji modelu wskazującej artefakty cudzego runu, a następnie odczyt tych plików przez inną ścieżkę API.

Wszystkie trzy problemy są naprawione w MLflow 3.15.0. Upstreamowe advisory pojawiły się wcześniej w sierpniu; wydarzeniem z 17 sierpnia była publikacja rekordów CVE. Nie należy przedstawiać ich jako jednego łańcucha ani dowodu trwającej kampanii. Razem pokazują jednak ważny problem platform ML: zaufanie nie kończy się na modelu. Obejmuje webhooki, tracking, lineage, registry, artefakty i politykę dostępu między nimi.

Najwyższy priorytet ma CVE-2026-64849, ocenione na 9,3 w CVSS 3.1. Podatny endpoint mógł być dostępny bez uwierzytelnienia w domyślnej konfiguracji serwera trackingowego. Dwa pozostałe błędy wymagają konta i dotyczą wdrożeń używających mechanizmu basic-auth oraz rozdzielonych uprawnień do runów, eksperymentów i modeli.

CVE-2026-64849: walidacja pierwszego URL nie kontroluje całego połączenia

MLflow obsługuje webhooki rejestru modeli. Przed wysłaniem żądania funkcja walidacyjna rozwiązywała nazwę hosta i odrzucała adresy prywatne, loopback oraz link-local. Taka kontrola wygląda rozsądnie, ale obejmowała tylko pierwotny URL. Biblioteka HTTP mogła następnie podążyć za przekierowaniem i ponownie rozwiązać nazwę bez sprawdzenia rzeczywistego adresu połączenia.

To klasyczny rozdźwięk między time of check i time of use. Bezpieczny publiczny host może odpowiedzieć redirectem do usługi wewnętrznej. DNS może też zwrócić publiczny adres podczas walidacji, a inny przy faktycznym połączeniu. Sprawdzenie ciągu URL ani pojedynczego wyniku DNS nie jest więc wystarczającą granicą SSRF.

Szczególnie istotny był endpoint testujący webhook. Zwracał status i treść odpowiedzi upstreamu, dzięki czemu ślepy SSRF stawał się odczytem. Z perspektywy infrastruktury MLflow mógł dotrzeć do loopback, prywatnego panelu lub usługi metadanych chmury. Faktyczny wpływ zależy od sieci, konfiguracji metadanych i uprawnień przypisanych do workloada.

Poprawka w 3.15.0 wprowadza kontrolę na etapie nawiązywania każdego połączenia. Adres peera jest sprawdzany przed wymianą HTTP, także po redirectach, co zamyka zarówno zmianę celu przez przekierowanie, jak i wyścig DNS. To silniejszy wzorzec niż ponowne parsowanie kolejnych nagłówków Location, ponieważ kontroluje miejsce, z którym socket naprawdę się połączył.

Dlaczego egress pozostaje potrzebny po aktualizacji

Walidacja aplikacyjna jest jedną warstwą. Serwer MLflow powinien mieć politykę egress blokującą metadane chmurowe, sieci zarządzające, bazy danych, API orkiestratora i lokalne porty administracyjne. Jeżeli webhooki mają trafiać tylko do zatwierdzonych systemów, jeszcze lepsza jest allowlista domen lub broker wyjściowy.

Reverse proxy powinien wymagać uwierzytelnienia dla interfejsu administracyjnego i API webhooków. Nie zakładaj, że „serwer trackingowy jest wewnętrzny”, jeśli ingress, tunel deweloperski albo błędna reguła chmurowa może wystawić go publicznie. Inwentaryzacja powinna objąć notebooki, tymczasowe środowiska eksperymentalne i kopie demonstracyjne.

Logi powinny zapisywać pierwotny host, łańcuch redirectów, znormalizowany adres docelowy i decyzję polityki, ale nie pełne sekrety w query stringu. Alertuj na próby dotarcia do adresów niepublicznych, nietypowe porty oraz webhooki testowane wielokrotnie przez anonimowe źródło.

CVE-2026-69146: brakujący handler usuwa kontrolę UPDATE

MLflow basic-auth przypisuje walidator uprawnień do klas żądań. Standardowe operacje zapisu metryk, parametrów i tagów sprawdzają, czy użytkownik może modyfikować run. Klasa LogInputs nie znalazła się jednak w mapie handlerów. Brak walidatora był interpretowany jako przejście dalej, a nie jawna odmowa.

Advisory CVE-2026-69146 opisuje możliwość dopisania kontrolowanego DatasetInput do lineage cudzego runu. Nie jest to odczyt wag ani wykonanie kodu, ale naruszenie integralności metadanych. W systemie audytującym pochodzenie danych fałszywy lineage może zmienić ocenę zgodności, reprodukowalność eksperymentu i decyzje o promocji modelu.

To przykład niebezpiecznego fail-open w rejestrze tras. Nowy endpoint nie powinien być dostępny, dopóki nie ma przypisanej jawnej polityki. Bezpieczniejszy projekt generuje błąd uruchomienia albo odmawia żądania, gdy mapowanie autoryzacji nie istnieje. Test kompletności powinien porównać wszystkie mutujące operacje z tabelą walidatorów.

Po aktualizacji warto przejrzeć historię zmian lineage. Szukaj zapisów wykonanych przez użytkownika innego niż właściciel runu, zwłaszcza przy braku innych legalnych operacji UPDATE. Nie zakładaj, że artefakt audytowy jest wiarygodny tylko dlatego, że pochodzi z tabeli MLflow.

CVE-2026-69148: bezpieczna ścieżka nie oznacza dozwolonego źródła

Podczas tworzenia wersji modelu MLflow sprawdzał, czy wskazana ścieżka artefaktu mieści się w katalogu określonego runu lub modelu. Kontrola chroniła przed klasycznym path traversal. Nie sprawdzała jednak, czy bieżący użytkownik ma prawo READ do wskazanego run_id lub model_id.

Advisory CVE-2026-69148 pokazuje różnicę między integralnością ścieżki a autoryzacją obiektu. Użytkownik posiadający własny model mógł utworzyć jego wersję, wskazując prawidłowy katalog artefaktów cudzego runu. Po zapisaniu relacji endpoint artefaktów wersji modelu ufał nowemu powiązaniu i zwracał pliki bez pierwotnej kontroli eksperymentu.

Wpływ obejmuje wagi, próbki danych treningowych, raporty ewaluacji i inne pliki przechowywane w artefaktach. Problem jest widoczny zwłaszcza wtedy, gdy organizacja rzeczywiście rozdziela eksperymenty między zespołami. W środowisku, gdzie wszyscy mają READ do wszystkiego, CVE nie tworzy dodatkowego odczytu, choć nadal ujawnia wadliwy kontrakt.

Autoryzacja musi być sprawdzana zarówno podczas tworzenia referencji, jak i podczas jej użycia. Sam zapis relacji nie może „wyprać” pochodzenia zasobu. Dobrą praktyką jest przechowywanie właściciela źródła oraz ponowna decyzja polityki przy każdym pobraniu artefaktu.

Plan działania dla właściciela MLflow

Zaktualizuj wszystkie serwery trackingowe i registry do 3.15.0 lub późniejszego wspieranego wydania. Zweryfikuj obraz kontenera, procesy uruchomione z notebooków i narzędzia CLI. Wersja biblioteki w środowisku klienta nie dowodzi wersji serwera.

Wymuś uwierzytelnienie na brzegu, ogranicz dostęp do API webhooków i zastosuj egress deny dla adresów wewnętrznych. Sprawdź rolę chmurową workloada MLflow; nie powinna mieć uprawnień szerszych niż potrzebne do magazynu artefaktów. Jeśli metadata service obsługuje tryb wymagający tokenu sesyjnego, włącz go jako dodatkową barierę.

Przejrzyj macierz uprawnień eksperyment–run–model–artefakt. Test negatywny powinien potwierdzić, że użytkownik A nie dopisze lineage do runu B i nie utworzy wersji modelu prowadzącej do artefaktów B. Test SSRF musi odbywać się w izolowanym środowisku i sprawdzać kontrolowaną odmowę po redirectach, bez kierowania ruchu do rzeczywistych usług wrażliwych.

Jeżeli logi wskazują dostęp do metadanych lub artefaktów, potraktuj sprawę jak incydent. Unieważnij potencjalnie ujawnione poświadczenia chmurowe, przeanalizuj pobrania plików i zweryfikuj integralność lineage używanego do decyzji produkcyjnych.

Fakty i wnioski Breachroad

Faktem jest, że trzy rekordy opublikowane 17 sierpnia obejmują nieuwierzytelniony SSRF, zapis lineage bez właściwego UPDATE oraz odczyt artefaktów przez brak kontroli źródłowego runu. MLflow 3.15.0 zawiera poprawki. Źródła nie dowodzą powszechnego aktywnego wykorzystania.

Wnioskiem Breachroad jest traktowanie platformy ML jak systemu wielodostępnego przechowującego kod, dane i poświadczenia. Kontrola URL, path containment i logowanie użytkownika są potrzebne, ale każda z nich chroni inną granicę. Bez autoryzacji obiektowej i kontroli sieci ich połączenie nadal pozostawia lukę.

Zespołom MLOps i deweloperskim polecamy szkolenia z bezpieczeństwa AI dla organizacji. Architekturę i uprawnienia platformy można dodatkowo zweryfikować przez AI red teaming oraz testy API.