MLflow Sicherheitslücke CVE-2026-64849: Cloud-Zugangsdaten in Gefahr

Die MLflow Sicherheitslücke CVE-2026-64849 wird nach Behördenangaben aktiv ausgenutzt. Die US-Cybersicherheitsbehörde CISA hat sie am 19. August 2026 in den Katalog bekannter ausgenutzter Schwachstellen (KEV) aufgenommen. Betroffen sind alle MLflow-Versionen vor 3.15.0 – und damit sehr viele KI- und Data-Science-Umgebungen, die im Hintergrund still vor sich hin laufen.

Was an MLflow konkret kaputt ist

MLflow ist eine quelloffene Plattform zum Verwalten von Machine-Learning-Experimenten, Modellen und Agenten. Der Fehler steckt in der Webhook-Funktion. Laut Eintrag in der NVD prüft der Endpunkt POST /api/2.0/mlflow/webhooks/{id}/test die angegebene Zieladresse zwar einmal, folgt beim Zustellen aber Weiterleitungen und löst den Hostnamen erneut auf, ohne die geprüfte Adresse festzunageln. Genau dazwischen setzt der Angriff an.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Das Ergebnis ist eine serverseitige Anfragefälschung (SSRF, CWE-918). Ein Angreifer bringt den MLflow-Server dazu, Anfragen an interne Adressen zu schicken – und bekommt Statuscode sowie Antwortkörper zurückgeliefert. Aus einer blinden Lücke wird damit eine, die tatsächlich Daten ausliest. Eine Anmeldung braucht es dafür nicht: Der Standard-Tracking-Server – gestartet mit mlflow server, ohne Authentifizierung – stellt die Webhook-API unauthentifiziert bereit.

• CVE: CVE-2026-64849
• CVSS 3.1: 9.3 (kritisch), Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
• Betroffen: alle MLflow-Versionen vor 3.15.0
• Behoben in: 3.15.0
• CISA-KEV: aufgenommen am 19.08.2026, Frist für US-Bundesbehörden 02.09.2026

Warum diese SSRF-Lücke besonders teuer wird

In der Cloud liegt hinter der internen Adresse 169.254.169.254 der Metadaten-Dienst. Wer ihn erreicht, bekommt oft die temporären Zugangsdaten jener Rolle, unter der die Maschine läuft. Sicherheitsforscher von watchTowr berichten laut SecurityWeek genau davon: Angreifer erreichen über die Lücke direkt die Cloud-Metadatendienste und ziehen Zugangsdaten sowie Geheimnisse ab.

Der Schaden endet damit nicht beim ML-Server. Er beginnt dort erst.

Was das für dich bedeutet

Aus CISO-Sicht ist nicht der CVSS-Wert die interessante Zahl, sondern die Reichweite. MLflow taucht in kaum einer Asset-Liste auf. Typischer Ablauf: Jemand aus dem Data-Science-Team startet „mal eben” einen Tracking-Server, damit Experimente nachvollziehbar bleiben. Standardmäßig ohne Anmeldung, im internen Netz erreichbar, manchmal versehentlich auch von außen. Nach ein paar Monaten weiß niemand mehr, wer ihn betreibt – laufen tut er trotzdem.

Dieses Muster kennt jeder, der lange genug mit Identity-Themen zu tun hatte. Es ist derselbe Mechanismus wie beim Dienstkonto, das vor Jahren „nur für einen Test” zu viele Rechte bekommen hat: Die Berechtigung bleibt, das Wissen darüber verschwindet. Deshalb lautet die wichtigste Frage hier nicht „Haben wir gepatcht?”, sondern „Welche Cloud-Rolle hängt an dieser Maschine, und was darf die eigentlich alles?”.

Ein zweiter Punkt geht in den Meldungen meist unter: Diese MLflow Sicherheitslücke reiht sich in ein Muster ein. Erst kürzlich war mit der Ray-Sicherheitslücke ein weiteres KI-Werkzeug betroffen. KI-Infrastruktur ist inzwischen ein eigenständiges Angriffsziel, wird aber selten so streng behandelt wie ein Produktivsystem. Wer seine Modelle stattdessen kontrolliert auf eigener Hardware für lokale KI und LLMs betreibt, umgeht zumindest den Cloud-Credential-Teil des Problems.

Was du jetzt tun solltest

• Auf MLflow 3.15.0 aktualisieren. Das ist der eigentliche Fix, alles andere bleibt Schadensbegrenzung.
• Zuerst suchen, wo MLflow überhaupt läuft. Container-Images, pip list, offene Ports (Standard 5000), interne DNS-Einträge. Was du nicht findest, patchst du auch nicht.
• Metadaten-Zugriff härten. Auf AWS IMDSv2 erzwingen und das Hop-Limit auf 1 setzen; bei Azure und Google Cloud den Zugriff auf den Metadaten-Endpunkt entsprechend einschränken.
• Rechte der Instanz-Rolle zusammenstreichen. Ein Experiment-Tracker braucht meist einen Storage-Bucket, nicht Lese- und Schreibrechte auf das halbe Konto.
• Nie ohne Authentifizierung exponieren. Ein Reverse Proxy mit Anmeldung davor kostet eine Stunde Arbeit.
• Bei Verdacht auf Ausnutzung: Cloud-Zugangsdaten rotieren und die Audit-Logs auf ungewöhnliche API-Aufrufe der betroffenen Rolle prüfen.

Ein Detail macht die Sache noch unangenehmer: Version 3.15.0 mit dem Fix erschien laut GitHub bereits am 31. Juli 2026. Die CVE-Nummer wurde erst am 17. August vergeben – und kurz darauf begann die Ausnutzung. Wer den Release im Juli eingespielt hat, war nie in Gefahr. Das ist der Normalfall bei Open-Source-Komponenten: Der Patch ist längst da, nur weiß im Betrieb niemand davon, weil das Werkzeug in keinem Inventar steht.

Die CISA-Frist bis 2. September gilt formal nur für US-Bundesbehörden. Als Richtwert für die eigene Planung taugt sie trotzdem, denn zwei Wochen sind bei einer aktiv ausgenutzten kritischen Lücke bereits großzügig bemessen.

Quellen

• NVD: CVE-2026-64849
• CISA: Adds One Known Exploited Vulnerability to Catalog (19.08.2026)
• BleepingComputer: CISA warns of hackers exploiting critical MLflow vulnerability
• SecurityWeek: MLflow Vulnerability Exploited for Cloud Credential Theft