MLflow unter Angriff: Kritische SSRF legt Cloud-Zugangsdaten und interne Dienste offen

CISA nimmt CVE-2026-64849 in den KEV-Katalog auf

CISA hat die aktive Ausnutzung von CVE-2026-64849 gemeldet, einer kritischen Schwachstelle in MLflow. Die Open-Source-Plattform wird zur Entwicklung, Bewertung und Überwachung von Machine-Learning-Modellen, KI-Anwendungen und Large Language Models eingesetzt.

Bei der Schwachstelle handelt es sich um eine Server-Side Request Forgery (SSRF) gemäß CWE-918. Ein nicht authentifizierter Angreifer kann den MLflow-Server dazu bringen, Anfragen an interne Ressourcen zu senden, die aus dem Internet nicht direkt erreichbar sind.

CVE-2026-64849 wurde am 19. August 2026 in den Katalog der CISA Known Exploited Vulnerabilities (KEV) aufgenommen. Für US-Bundesbehörden ist die Frist zur Behebung auf den 2. September 2026 festgelegt.

Die Schwachstelle hat einen CVSS-3.1-Wert von 9,3 mit folgendem Vektor:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Der Wert berücksichtigt, dass keine Authentifizierung erforderlich ist, die Schwachstelle remote ausgenutzt werden kann und die Auswirkungen auf die Vertraulichkeit hoch sind. CISA stuft die Ausnutzung außerdem als aktiv, automatisierbar und mit vollständigen technischen Auswirkungen ein.

Den verfügbaren Informationen zufolge begannen Angreifer bereits wenige Stunden nach der CVE-Vergabe mit der Suche nach verwundbaren MLflow-Systemen. CISA hat keine weiteren Details zu den beobachteten Angriffen veröffentlicht.

Welche MLflow-Installationen gefährdet sind

Das Risiko betrifft vor allem Tracking Server, die mit folgendem Befehl gestartet werden:

mlflow server

und ohne Authentifizierung mit der standardmäßigen SQLite-Datenbank konfiguriert sind:

sqlite:///mlflow.db

Diese Konfiguration ist relevant, weil die Webhooks der Model Registry einen SQL-Store voraussetzen. Der Standardserver erfüllt damit die Voraussetzungen für die exponierten APIs.

Besonders gefährdet ist ein Tracking Server, wenn er:

• aus dem Internet erreichbar ist;
• keine Authentifizierung verlangt;
• auf interne Netzwerke oder Cloud-Dienste zugreifen kann;
• die Metadata-Endpunkte von Instanzen erreichen kann;
• die Webhook-Funktionen der Model Registry nutzt.

MLflow verzeichnet mehr als 30 Millionen Downloads pro Monat und wird von Tausenden Organisationen eingesetzt. Die Schwachstelle kann daher Entwicklungsumgebungen, MLOps-Plattformen und Cloud-Infrastrukturen betreffen, auf denen KI-Modelle oder -Pipelines betrieben werden.

Die Angaben zu den betroffenen Versionen sind in den Advisories nicht vollständig einheitlich. NVD stuft alle Versionen vor 3.15.0 als verwundbar ein. Das GitHub Security Advisory nennt dagegen Versionen bis einschließlich 3.13.0, beschreibt die Behebung jedoch in Release 3.15.0 und im Patch #24258.

Der Exploit wurde auf MLflow 3.13.0 mit der standardmäßigen SQLite-Datenbank bestätigt. Aus Vorsichtsgründen sollten Installationen vor 3.15.0 als verwundbar behandelt werden.

So funktioniert der SSRF-Bypass

Der zentrale Angriffsweg nutzt den nicht authentifizierten Endpunkt:

POST /api/2.0/mlflow/webhooks/{id}/test

Der Endpunkt dient zum Testen eines Webhooks und gibt dem Aufrufer den Status der vom entfernten Dienst erhaltenen Antwort einschließlich des Antwortinhalts zurück.

MLflow prüft die Webhook-URL zunächst. Dabei werden das Schema und der Hostname überprüft, und nicht öffentliche Adressen werden abgelehnt – darunter private, Loopback- und Link-Local-Adressen sowie Adressen von Metadata-Diensten. Normalerweise ist ausschließlich das Schema https zulässig.

Die Prüfung bindet die ermittelte IP-Adresse jedoch nicht an die nachfolgende Verbindung. Die Delivery-Komponente:

• folgt HTTP-Redirects automatisch;
• deaktiviert allow_redirects nicht;
• überprüft die URL im Location-Header nicht erneut;
• kann beim Verbindungsaufbau eine erneute DNS-Auflösung durchführen.

Ein Angreifer kann daher einen Webhook auf einen scheinbar legitimen öffentlichen HTTPS-Host registrieren. Nachdem die Validierung erfolgreich durchlaufen wurde, antwortet der eigene Server mit einem 302-Redirect auf eine interne Ressource, etwa:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Der MLflow-Server folgt dem Redirect und sendet die Anfrage aus seiner eigenen Netzwerkumgebung. Der /test-Endpunkt gibt dem Angreifer anschließend den HTTP-Statuscode und den Antwortinhalt des Upstream-Dienstes zurück.

Der zweite Bypass nutzt DNS-Rebinding. Die DNS-Auflösung während der ersten Prüfung kann eine öffentliche Adresse liefern, während die von der HTTP-Bibliothek beim Verbindungsaufbau durchgeführte Auflösung auf eine interne Adresse zeigt. Da die genehmigte IP-Adresse bei der Validierung nicht festgehalten wird, kann die Anfrage ein anderes Ziel erreichen.

Die Schwachstelle ermöglicht den Zugriff auf:

• AWS-IMDS-Endpunkte und andere Cloud-Metadata-Dienste;
• interne Verwaltungsdienste;
• Loopback-Adressen;
• Ports und Hosts in privaten Netzwerken;
• Systeme außerhalb des eigenen Netzwerkperimeters.

Der Zugriff auf Cloud-Metadaten kann temporäre AWS-IAM-Zugangsdaten, Tokens und weitere Geheimnisse offenlegen. Die SSRF kann außerdem für Port-Scanning und die Erkennung interner Hosts genutzt werden.

Das Advisory unterscheidet zwischen einer „blinden“ SSRF im normalen Event-Zustellungsweg und einer SSRF mit Auslesen der Antwort, die über den /test-Endpunkt möglich ist.

PoC demonstriert das Abrufen interner Daten

Die veröffentlichte Demonstration umfasst drei Schritte.

Zunächst wird versucht, einen Webhook auf eine lokale Adresse wie 127.0.0.1 zu registrieren. Die Prüfung antwortet mit einem HTTP-400-Fehler, da Schema oder Adresse nicht zulässig sind.

Anschließend wird ein Webhook auf einen vom Angreifer kontrollierten öffentlichen HTTPS-Host registriert. Die URL besteht die Validierung und wird akzeptiert.

Zum Schluss antwortet der Server des Angreifers mit einem Redirect auf einen internen Dienst. Der Angreifer ruft daraufhin den /test-Endpunkt auf, der eine Struktur wie die folgende zurückgeben kann:

{
  "result": {
    "success": true,
    "response_status": 200,
    "response_body": "<Inhalt des internen Dienstes>"
  }
}

In einem lokalen Test fügte der Forscher manuell Werte wie die folgenden in den internen Dienst ein:

INTERNAL_SECRET=mlflow_ssrf_proof_7f3a91
role=admin

Dabei handelte es sich nicht um echte Cloud-Zugangsdaten. Der Test zeigt jedoch, dass der Inhalt einer internen Antwort an den Angreifer übertragen werden kann.

Der Angriff erfordert keine Authentifizierung und wird vom MLflow-Server ausgeführt, nicht vom Browser oder Computer des Opfers. Die Event-Werte müssen außerdem Proto-Namen in Großbuchstaben verwenden, etwa REGISTERED_MODEL und CREATED.

Patch, Abhilfemaßnahmen und Reaktion

Die Korrektur ist in MLflow 3.15.0 verfügbar und mit dem Pull Request #24258 sowie folgendem Commit verknüpft:

ba949522477cbd5915aa55d29b0cfad7d5ddf939

Das Projekt hat den SSRFProtectedHTTPAdapter eingeführt. Dieser prüft die IP-Adresse des Remote-Sockets unmittelbar nach dem Verbindungsaufbau und vor dem TLS- oder HTTP-Austausch. Die Prüfung gilt auch für Redirects und verhindert, dass der Bypass über 302-, 307- und 308-Antworten erneut genutzt wird.

Damit wird auch das DNS-Rebinding-Problem behoben: Es wird die tatsächlich erreichte IP-Adresse überprüft, statt sich ausschließlich auf die anfängliche Auflösung zu verlassen.

Administratoren sollten:

1. MLflow auf Version 3.15.0 oder höher aktualisieren;
2. öffentlich erreichbare und nicht authentifizierte Tracking Server priorisieren;
3. eine wirksame Authentifizierung aktivieren und die Berechtigungen der Webhooks prüfen;
4. ausgehende Verbindungen des MLflow-Prozesses beschränken;
5. den Zugriff auf 169.254.169.254, private Netzwerke, Loopback-Adressen und nicht benötigte Verwaltungsdienste blockieren;
6. Proxy, Firewall und Egress-Filtering so konfigurieren, dass Anfragen an interne Ziele verhindert werden.

Die Logs sollten auf Anfragen an folgende Pfade untersucht werden:

/api/2.0/mlflow/webhooks
/api/2.0/mlflow/webhooks/{id}/test

Verdächtig sind außerdem die Registrierung von Webhooks auf unerwartete externe Hosts, Redirects auf private Adressen und Zugriffe auf 169.254.169.254.

Wenn eine Ausnutzung der Instanz möglich ist, muss geprüft werden, ob Cloud-Zugangsdaten, Tokens oder Geheimnisse offengelegt wurden. Potenziell kompromittierte AWS-IAM-Zugangsdaten sollten widerrufen oder rotiert werden. Zusätzlich ist eine Analyse nachfolgender Nutzung erforderlich.

Die Schwachstelle wurde am 12. Juni 2026 von @freeman-bb vertraulich gemeldet. Eine unabhängige Prüfung durch @AUTHENSOR wurde am 26. Juni 2026 im Issue #24179 veröffentlicht.

CVE-2026-64849 darf nicht mit CVE-2025-14279 verwechselt werden. Letztere betrifft eine CSRF-Schwachstelle mit DNS-Rebinding und gehört zur Kategorie CWE-352, nicht zu einer serverseitigen SSRF dieser Art.