MLflow 3 Trial

Überblick

MLflow ist eine offene Plattform für den Machine-Learning-Lifecycle, die in MLflow 3 um produktionsreife generative KI-Fähigkeiten — Tracing, Prompt- und App-Versionsverfolgung, LLM-Judge-Evaluation und Feedback-Erfassung — erweitert wurde, zusätzlich zum gewohnten Experiment-Tracking und der Model Registry (MLflow 3 release, Announcing MLflow 3). Databricks beschreibt MLflow als das Fundament für MLOps im großen Maßstab, mit über 30 Millionen Downloads pro Monat und mehr als 850 Contributors (Databricks). Der Production-Footprint hat sich nicht verändert, und ebenso wenig die Empfehlung, es als System of Record für Runs, Modelle und Traces zu nutzen.

Der Ring wechselt aus Gründen der Sicherheitslage von Adopt zu Trial, nicht aus Produktgründen. CVE-2026-64849 ist eine kritische (CVSS v3.1 9.3), nicht authentifizierte Server-Side-Request-Forgery im Webhook-Test-Endpoint von MLflow, die alle Versionen vor 3.15.0 betrifft; da der Endpoint die Upstream-Antwort an den Aufrufer zurückspiegelt, kann ein Angreifer per DNS-Rebinding Cloud-Instance-Metadata-Credentials für AWS, GCP oder Azure direkt aus dem Server auslesen (Cloud Security Alliance). Das Honeypot-Netzwerk von watchTowr beobachtete, wie Angreifer aus dem Internet erreichbare Tracking-Server innerhalb von Stunden nach der öffentlichen Zuweisung der CVE am 17. August 2026 scannten und ausnutzten, und CISA nahm die Schwachstelle in den Known Exploited Vulnerabilities-Katalog auf.

Das ist keine Geschichte einer einzelnen CVE. Zehn zwischen dem 3. April und dem 17. August 2026 veröffentlichte Advisories beschreiben fehlende oder fehlerhaft angewendete Autorisierungsprüfungen an MLflow-Endpoints, wobei das Basic-Auth-Plugin fail open agiert, wenn ein Endpoint in seiner Handler-Map fehlt (Particula). Trial bedeutet: weiter betreiben — mit Patching auf 3.15.0 oder neuer, Netzwerkisolation und der Vorgabe, dass keine exponierten Tracking-Server als Hard Gate behandelt werden, nicht als Hardening-Backlog-Punkt.

Adoptionssignale

• MLflow 3 vereint explizit traditionelles ML, Deep Learning und GenAI: derselbe Instrumentierungs-, Registry- und Monitoring-Pfad bedient eine Trainingspipeline und ein Multi-Agent-RAG-System (Announcing MLflow 3).
• Die Release-Kadenz bleibt hoch und produktgetrieben: 3.14.0 lieferte mlflow agent setup, Review-Queues, eine Evaluation-Dataset-UI und eine pytest-Integration, die GenAI-Qualität in der CI gated (3.14.0 release notes); spätere Releases fügten eine MCP Registry und beschreibbare Trace-Ansichten hinzu (releases).
• Managed MLflow 3 auf Azure Databricks bewahrt die Kernkonzepte des MLflow-2.x-Tracking und ergänzt LoggedModels sowie gestaffelte Deployment-Jobs, was die Migration für bestehende Nutzer reibungsarm hält (Azure Databricks).
• Das Projekt selbst veröffentlicht inzwischen Standardisierungsempfehlungen für Enterprises, die Identity- und Access-Posture, Registries, Evaluationskriterien und ein einheitliches Observability-Schema abdecken (MLflow).
• LoggedModel als eigenständige Entität entkoppelt das Modell vom Run, der es erzeugt hat, was Promotion und Lineage in Produktionspipelines vereinfacht (field write-up).

Risiken

• Aktiv ausgenutzte, nicht authentifizierte SSRF. CVE-2026-64849 (CVSS 9.3) erlaubt es einem nicht authentifizierten Aufrufer, POST /api/2.0/mlflow/webhooks/{id}/test auf interne Adressen wie 169.254.169.254 zu richten und die zurückgespiegelte Antwort zu lesen, was Cloud-IAM-Tokens und Service-Account-Keys liefert; Exploitation wurde innerhalb von Stunden nach der Disclosure in freier Wildbahn beobachtet (CSA).
• Die Ursache ist eine TOCTOU-Lücke, kein Filterfehler. _validate_webhook_url() prüft das Ziel zum Zeitpunkt der Registrierung, während der Delivery-Code Redirects folgt und Hostnamen ohne Pinning der validierten IP erneut auflöst — sodass Allowlist-artige Mitigations unterhalb von 3.15.0 die Lücke nicht schließen (CSA).
• Autorisierung ist per Design fail open. Das Basic-Auth-Plugin löst jeden Request gegen ein 120-Einträge-Dictionary auf und überspringt die Prüfung bei einem Miss; nur das /mlflow/traces/-Prefix ist fail closed, und CVE-2026-71211 (7.1), die CreateGatewaySecret betrifft, hatte bei 3.15.2 noch keine dokumentierte fehlerbereinigte Version (Particula).
• Cross-Tenant-Artefakt-Reads. CVE-2026-69148 erlaubt es einem authentifizierten Nutzer, die run_id eines anderen Nutzers in CreateModelVersion zu referenzieren und dadurch beliebige Dateien aus dem Artifact-Verzeichnis des Opfers zu lesen, wobei das Experiment-Level-READ-Gate umgangen wird (GitHub Advisory).
• Sicherheit wurde nachträglich angeflanscht, nicht von Anfang an mitgedacht. Standard-MLflow-Deployments haben keine Authentifizierung, keine Autorisierung und keine Isolation, sodass Multi-Tenant- oder Shared-Installationen gezieltes Engineering benötigen, bevor sie produktionstauglich sind (redteams.ai).
• Legacy-Risiko beim Model-Loading besteht weiter. CVE-2024-37058 (CVSS 8.8) erlaubt es einem bösartig hochgeladenen LangChain-AgentExecutor-Modell, beim Laden beliebigen Code auszuführen, was überall relevant ist, wo Registry-Writes nicht vollständig automatisiert sind (Meterian).

Empfehlung

MLflow 3 sollte weiterhin das System of Record für Trainingsruns, registrierte Modelle und GenAI-Traces bleiben — aber die Sicherheitsarbeit ist in diesem Quartal als Voraussetzung zu behandeln, nicht als Follow-up. Inventarisieren Sie jeden Tracking-Server, einschließlich vergessener Team-Instanzen und allem, was hinter einem Load Balancer versteckt ist, und bestätigen Sie die laufende Version. Alles unterhalb von 3.15.0 ist von CVE-2026-64849 betroffen und sollte sofort gepatcht werden; gehen Sie bei jeder aus dem Internet erreichbaren Instanz von einer Kompromittierung aus, rotieren Sie die Instance-Role- und Service-Account-Credentials, die diese erreichen konnte, und überprüfen Sie die Zugriffsprotokolle des Metadata-Service (CSA).

Entfernen Sie die Internet-Exposition als dauerhafte Kontrolle. Platzieren Sie Tracking-Server hinter einem authentifizierenden Reverse-Proxy oder in einem privaten Netzwerk, erzwingen Sie IMDSv2-artige Metadata-Schutzmaßnahmen auf den Hosts und beschränken Sie den Egress vom MLflow-Server, damit eine zukünftige SSRF nirgendwo Nützliches hinführt. Verlassen Sie sich nicht auf das gebündelte Basic-Auth-Plugin als Autorisierungsgrenze: Es ist fail open für Endpoints, die in seiner Handler-Map fehlen, also grenzen Sie Trust auf Netzwerk- und Proxy-Ebene ein und halten Sie getrennte Instanzen für Tenants vor, die die Artefakte des jeweils anderen nicht lesen dürfen (Particula).

Auf der Plattformseite gilt die bisherige Empfehlung weiterhin: Erzwingen Sie Retention-Policies für das Trace-Logging bei geschwätzigen Agents, gaten Sie Promotion mit Evaluationskriterien in der CI — die pytest-Integration von 3.14.0 macht das konkret (3.14.0) —, standardisieren Sie Autologging pro Sprache, und blockieren Sie manuelle Registry-Writes außerhalb der Automatisierung, was auch den Pfad für bösartiges Model-Loading einschränkt. Nehmen Sie MLflow in jeden Prozess auf, der CISA KEV und den mlflow-Advisory-Feed beobachtet; zehn Autorisierungs-Advisories in fünf Monaten bedeuten, dass Patch-Latenz — nicht Feature-Auswahl — der entscheidende Faktor ist, um dies zurück nach Adopt zu verschieben.

Quellen

• MLflow 3 release
• Announcing MLflow 3
• MLflow 3.14.0 release notes
• MLflow releases
• Databricks: MLflow 3.0
• Get started with MLflow 3 for models — Azure Databricks
• Why Standardize AI Workflows for Enterprise MLOps
• CSA: MLflow SSRF Actively Exploited for Cloud Credential Theft
• CSA: MLflow SSRF Flaw Actively Exploited for Credential Theft
• MLflow Tracking Server Security: Basic Auth Is Not Enough
• CVE-2026-69148 GitHub Advisory
• MLflow Attack Surface
• Can an Unpatched MLflow Server Expose Cloud Credentials and Model Weights?
• Meterian: mlflow 3.5.0 known vulnerabilities
• Building Production ML Pipelines with MLflow 3.0

Überblick

MLflow ist eine offene Plattform für den kompletten ML-Lifecycle, in MLflow 3 erweitert um GenAI Tracing, Prompt Management und Evaluations neben Experiments und Model Registry (MLflow Dokumentation).

Adopt, wenn ihr eine vendor-neutrale Control Plane für Experiments, Models und GenAI Traces wollt, die mit Databricks, Kubernetes oder Self-Hosting integriert. Kombiniert mit Inference Gateway und Feature Store statt Ersatz.

Adoptionssignale

• MLflow 3 Dokumentation positioniert GenAI Tracing neben klassischem Run Tracking.
• Databricks-Kunden erben managed MLflow mit Enterprise Auth und Audit.
• OpenTelemetry-Export-Pfade korrelieren MLflow Traces mit APM Stacks.
• Community-Adoption bleibt hoch für sklearn, PyTorch und LangChain Instrumentation.

Risiken

• Unbegrenztes Trace Logging für gesprächige Agents steigert Storage-Kosten schnell.
• Model Promotion ohne Evaluation Gates reproduziert Registry-Fehler.
• Multi-Tenant Deployments brauchen Auth Plugins; Default-Installs sind nicht produktionsreif.
• Überlappendes LangSmith oder Vendor Tracing dupliziert Telemetrie ohne Standards.

Empfehlung

Adoptiert MLflow 3 als System of Record für Training Runs, registrierte Models und GenAI Traces, mit Retention Policies und Promotion Workflows in CI. Standardisiert Autologging pro Sprache und blockiert manuelle Registry Writes außerhalb Automation.

Quellen

• MLflow documentation
• MLflow 3
• MLflow GenAI tracing
• MLflow Model Registry