MLflow: Was die kritische Schwachstelle bedeutet

Viele KI-Anwendungen entstehen nicht in einem einzigen Arbeitsschritt. Teams testen verschiedene Modelle, Datenstände und Einstellungen. Sie vergleichen Ergebnisse, geben eine bestimmte Modellversion frei und stellen diese später für eine Anwendung bereit. MLflow hilft, diesen Weg nachvollziehbar zu machen.

Die Plattform kann Experimente und Trainingsläufe dokumentieren, Parameter und Qualitätswerte speichern, Dateien und Modelle als Artefakte zuordnen sowie Modellversionen in einem Register verwalten. Databricks stellt dafür einen gehosteten MLflow-Dienst bereit. Amazon SageMaker bietet ebenfalls verwaltete MLflow-Tracking-Server an. Für die Benutzer der späteren KI-Anwendung bleibt diese technische Schicht meistens unsichtbar.

Genau deshalb ist die Schwachstelle CVE-2026-64849 relevant. MLflow kann im Hintergrund mit internen Diensten, Speicherorten und Cloud-Identitäten verbunden sein. Wird eine solche Plattform zum Einfallstor, betrifft das nicht nur ein einzelnes Experiment.

Was die Schwachstelle direkt ermöglicht

Die Lücke liegt in der Verarbeitung von Webhooks. Webhooks informieren andere Systeme automatisch über Ereignisse, beispielsweise über eine neue Modellversion. Im beschriebenen Standardbetrieb konnte ein erreichbarer MLflow-Server ohne Authentisierung dazu gebracht werden, einer Weiterleitung zu einem internen Ziel zu folgen und die Antwort zurückzugeben.

Diese Angriffstechnik heisst Server-Side Request Forgery, kurz SSRF. Vereinfacht gesagt nutzt der Angreifer den MLflow-Server als Leser innerhalb eines Netzes, das er von aussen nicht direkt erreichen kann. Das Herstelleradvisory nennt interne Dienste und Cloud-Metadaten als mögliche Ziele.

Die kanadische Cyberbehörde dokumentierte am 19. August 2026, dass CISA die Schwachstelle in den Katalog der bekannten aktiv ausgenutzten Schwachstellen aufgenommen hat. Ihr Advisory nennt MLflow-Versionen vor 3.15.0 als betroffen. Das Herstelleradvisory dokumentiert zusätzliche Härtungen für IPv6-Übergänge in Version 3.16.0.

Das direkte Risiko ist der Verlust von Vertraulichkeit

Ein erfolgreicher Angriff kann Informationen aus internen Diensten offenlegen. Besonders kritisch sind Cloud-Metadaten, wenn darüber temporäre Zugangsdaten oder technische Identitäten erreichbar werden. Auch interne Schnittstellen, Systeminformationen und nicht öffentlich erreichbare Dienste können sichtbar werden.

Die Schwachstelle verändert jedoch nicht automatisch Experimente, Trainingsdaten oder Modellversionen in MLflow. Eine solche Behauptung wäre zu weit. Das Herstelleradvisory bewertet die direkte Auswirkung auf die Vertraulichkeit als hoch, auf die Integrität als niedrig und auf die Verfügbarkeit als nicht gegeben.

Wann daraus ein Integritätsrisiko wird

Das Folgerisiko hängt von den Berechtigungen der erreichbaren Identitäten und Dienste ab. Erlangt ein Angreifer Zugangsdaten mit Schreibrechten, könnten je nach Architektur Modellartefakte, Speicherinhalte, Bereitstellungen oder andere Cloud-Ressourcen verändert werden. Besitzen die erreichbaren Zugänge nur Leserechte, bleibt der mögliche Schaden entsprechend begrenzter.

Darum reicht die Frage nach der installierten MLflow-Version nicht aus. Die Organisation muss auch wissen, welche Daten, Artefakte, internen Dienste und Cloud-Ressourcen der MLflow-Server erreichen kann und welche Rechte seine technischen Identitäten besitzen.

Was jetzt geklärt werden muss

Zuerst braucht es ein Inventar aller selbst betriebenen und verwalteten MLflow-Instanzen. Für jede Instanz sind Erreichbarkeit, Version, Authentisierung, Webhook-Nutzung, Netzwerkpfade und Cloud-Berechtigungen zu prüfen. Danach folgen Update, Begrenzung unnötiger Zugriffe und die Suche nach Hinweisen auf eine mögliche Ausnutzung.

Verantwortung darf dabei nicht zwischen Data Science, Cloud-Team und IT-Betrieb verschwinden. Es muss klar sein, wer die technische Behebung umsetzt, wer die möglichen Folgewirkungen untersucht und wer ein verbleibendes Risiko bis zum Abschluss verantwortet.

Konsequenz

MLflow ist kein Modell und keine sichtbare KI-Anwendung. Es ist eine Betriebs- und Nachweisschicht hinter KI-Entwicklung und Modellbereitstellung. Sobald diese Schicht interne Dienste oder Cloud-Identitäten erreichen kann, gehört sie in denselben Inventar-, Berechtigungs-, Exposure- und Patchprozess wie jede andere produktive Plattform.

Quellen

• MLflow: Security Advisory GHSA-7gwp-5pfp-969j
• Canadian Centre for Cyber Security: Advisory AV26-832
• Databricks: MLflow on Databricks
• AWS: Managed MLflow on Amazon SageMaker AI