Ein MLflow-Tracking-Server steht für viele Teams zwischen Experimenten, Modellregistrierung und produktiver KI-Infrastruktur. Genau deshalb ist die aktuelle Schwachstelle CVE-2026-64849 mehr als ein gewöhnlicher Webfehler: Angreifer nutzen sie nach Angaben der US-Behörde CISA bereits aus. Über die Webhook-Funktion kann ein erreichbarer MLflow-Server dazu gebracht werden, interne Dienste oder Cloud-Metadaten abzurufen und Antworten nach außen zurückzugeben. Damit wird eine KI-Engineering-Plattform zum möglichen Sprungbrett für den Diebstahl temporärer Cloud-Zugangsdaten.
CISA nahm die Schwachstelle am 19. August 2026 in den Known Exploited Vulnerabilities Catalog auf. Bundesbehörden müssen die vorgegebenen Maßnahmen bis zum 2. September umsetzen. Für Unternehmen ist diese Frist nicht verbindlich, aber das Signal eindeutig: Wer MLflow betreibt, sollte Exposition, Version und mögliche Kompromittierung jetzt prüfen – nicht erst im nächsten regulären Patchfenster.
Technischer Kern: geprüfte URL, ungeprüfter Zielserver
MLflow unterstützt Webhooks für Ereignisse in der Model Registry. Damit können nachgelagerte Prozesse informiert werden, wenn beispielsweise ein Modell registriert wird. Zum Schutz vor Server-Side Request Forgery (SSRF) prüfte MLflow die konfigurierte Webhook-Adresse: Der Hostname wurde per DNS aufgelöst und private, lokale oder Link-Local-Adressen sollten abgewiesen werden.
Die Kontrolle hatte jedoch zwei Lücken. Erstens folgte die HTTP-Bibliothek Weiterleitungen, ohne das neue Ziel erneut nach denselben Regeln zu prüfen. Ein öffentlich erreichbarer HTTPS-Endpunkt konnte die Eingangskontrolle bestehen und anschließend auf einen internen Dienst weiterleiten. Zweitens wurden die bei der Prüfung ermittelten IP-Adressen nicht an die spätere Verbindung gebunden. Bei einem DNS-Rebinding-Angriff konnte der Hostname während der Prüfung auf eine öffentliche, beim tatsächlichen Verbindungsaufbau aber auf eine interne Adresse zeigen.
Besonders kritisch ist der Webhook-Testendpunkt. Auf einem standardmäßig ohne Authentifizierung gestarteten Open-Source-Tracking-Server kann er laut GitHub Security Advisory nicht nur den serverseitigen Abruf auslösen, sondern auch Status und Antwortinhalt zurückliefern. Dadurch entsteht eine Full-Read-SSRF: Der Angreifer erhält nicht nur einen Hinweis, dass ein interner Dienst erreichbar ist, sondern kann dessen Antwort lesen. Das Advisory bewertet CVE-2026-64849 mit CVSS 9,3 von 10.
Warum Cloud-Metadaten das Risiko vergrößern
In Cloud-Umgebungen laufen MLflow-Instanzen häufig mit einer Maschinenidentität, etwa einer Instanz- oder Workload-Rolle. Metadatendienste stellen dafür kurzlebige Zugangsdaten und Konfigurationsinformationen innerhalb der Infrastruktur bereit. Sie sind normalerweise nicht aus dem Internet erreichbar, wohl aber vom jeweiligen Workload aus. Eine SSRF verlagert den Abruf in genau diesen vertrauenswürdigen Kontext.
CISA beschreibt ausdrücklich, dass die Schwachstelle interne oder Cloud-Metadatendienste erreichen und response_status sowie response_body zurückgeben kann. The Hacker News berichtete unter Berufung auf Honeypot-Telemetrie von watchTowr, dass Angreifer exponierte MLflow-Instanzen scannten und versuchten, Cloud-Credentials und Secrets von bekannten internen Adressen abzurufen. Die Aktivität sei innerhalb weniger Stunden nach Vergabe der CVE-Kennung beobachtet worden.
Das bedeutet nicht automatisch, dass jede verwundbare Instanz kompromittiert wurde. Entscheidend sind Erreichbarkeit, Version, Authentifizierung, Netzwerkpfade und die Rechte der MLflow-Identität. Ein öffentlich exponierter Standardserver mit weitreichender Cloud-Rolle hat jedoch einen deutlich größeren möglichen Schadensradius als eine intern segmentierte Instanz mit minimalen Berechtigungen.
Fix in MLflow 3.15.0
MLflow hat die Schutzlogik in Version 3.15.0 geändert. Der neue Mechanismus prüft die IP-Adresse des tatsächlich aufgebauten Sockets unmittelbar nach dem Verbindungsaufbau und vor TLS- oder HTTP-Datenverkehr. Die Kontrolle gilt auch für neue Verbindungen infolge von Weiterleitungen. Damit wird nicht mehr nur der ursprüngliche Hostname bewertet, sondern der reale Verbindungspartner.
Nach NVD-Angaben sind Versionen vor 3.15.0 betroffen; die offizielle Release-Seite nennt den entsprechenden Fix ausdrücklich. Unternehmen sollten deshalb auf 3.15.0 oder eine neuere, vom Projekt freigegebene Version aktualisieren. Wo ein sofortiges Upgrade nicht möglich ist, sollte der Server aus nicht vertrauenswürdigen Netzen unerreichbar sein und ausgehende Verbindungen zu Metadaten-, Loopback- und internen Verwaltungsdiensten müssen technisch blockiert werden. Eine vorgeschaltete Anmeldung allein reduziert das Risiko, ersetzt aber weder Patch noch Egress-Kontrolle.
Was Unternehmen jetzt konkret tun sollten
1. MLflow vollständig inventarisieren. Nicht nur zentrale Plattformen zählen. Auch Notebook-Server, temporäre Testumgebungen, Kubernetes-Namespaces und von einzelnen Teams gestartete Tracking-Server können erreichbar sein. Erfasst werden sollten Version, Betriebsmodus, öffentliche Exposition, Authentifizierung und verwendete Cloud-Identität.
2. Upgrade und Exposition priorisieren. Internet-erreichbare oder mandantenübergreifend genutzte Instanzen gehören zuerst auf mindestens Version 3.15.0. Direkter Zugriff auf den Tracking-Server sollte grundsätzlich vermieden werden; Reverse Proxy, starke Authentifizierung und segmentierte Zugriffswege sind sinnvolle zusätzliche Kontrollen.
3. Egress begrenzen. MLflow benötigt nicht automatisch Zugriff auf jedes interne Netz. Firewall-, Service-Mesh- oder Cloud-Netzwerkregeln sollten Verbindungen zu Metadatendiensten, lokalen Verwaltungsinterfaces und nicht benötigten RFC1918-Netzen blockieren. Erlaubte Webhook-Ziele lassen sich zusätzlich per Allowlist einschränken.
4. Identitäten verkleinern und Secrets rotieren. Die Workload-Rolle des Servers sollte nur auf tatsächlich benötigte Artefakt- und Registrierungsressourcen zugreifen dürfen. Wenn Logs oder Netzwerkdaten verdächtige Webhook-Tests, ungewöhnliche Weiterleitungen oder Zugriffe auf Metadatenadressen zeigen, sind erreichbare Zugangsdaten als potenziell offengelegt zu behandeln. Dann reichen Patchen und Neustart nicht: Tokens, Schlüssel und Rollen-Sessions müssen widerrufen beziehungsweise rotiert und nachgelagerte Aktivitäten geprüft werden.
5. Forensik nicht durch Schnellreparatur verlieren. Vor dem Neuaufsetzen sollten HTTP-, Proxy-, DNS-, Cloud-Audit- und Netzwerklogs gesichert werden. Relevant sind neu angelegte Webhooks, Aufrufe des Testendpunkts, Verbindungen zu ungewöhnlichen externen Hosts, Weiterleitungen sowie Zugriffe des MLflow-Workloads auf interne Dienste.
Branchenkontext: MLOps ist produktive Kontrollinfrastruktur
Der Fall zeigt ein wiederkehrendes Muster. KI-Plattformen werden oft aus Experimentierumgebungen heraus produktiv, behalten aber großzügige Netzwerkpfade und Maschinenrechte. Gleichzeitig verbinden sie Modellartefakte, Registries, Webhooks, Object Storage, Datenquellen und zunehmend Agenten- oder MCP-Funktionen. Klassische Webrisiken wie SSRF treffen dadurch auf besonders privilegierte Infrastruktur.
Die richtige Reaktion ist weder Panik noch ein pauschales Verbot von MLflow. Unternehmen sollten MLOps-Dienste aber wie CI/CD-, GitOps- oder Observability-Kontrollsysteme behandeln: mit Asset-Verantwortung, zeitnahen Security-Updates, minimalen Identitäten, restriktivem Egress und belastbarer Protokollierung.
Risiken und Limitierungen der aktuellen Lage
Öffentlich bestätigt sind die Aufnahme in den CISA-KEV-Katalog und Berichte über Scans beziehungsweise Ausnutzungsversuche. Nicht öffentlich belegt sind eine Opferzahl, eine konkrete Kampagne oder Ransomware-Nutzung; CISA führt Letztere als unbekannt. Auch erlaubt die Meldung keine Aussage, welche Cloud-Konten tatsächlich kompromittiert wurden. Die Bewertung muss deshalb instanzbezogen erfolgen.
Fazit
CVE-2026-64849 macht sichtbar, wie schnell aus einer URL-Prüfung ein Cloud-Identitätsproblem werden kann. Der wichtigste Schritt ist das Upgrade auf MLflow 3.15.0 oder neuer. Nachhaltig sicher wird die Umgebung aber erst, wenn Netzwerk-Egress, Workload-Rechte und Forensik mitgedacht werden. Eine KI-Plattform darf nur deshalb interne Dienste erreichen, weil es für ihren Betrieb erforderlich ist – nicht weil das Labornetz historisch alles erlaubt.
