MLflow 3 Trial
Overview
MLflow is an open platform for the machine learning lifecycle, extended in MLflow 3 with production-grade generative AI capabilities — tracing, prompt and app version tracking, LLM-judge evaluation, and feedback collection — alongside the familiar experiment tracking and model registry (MLflow 3 release, Announcing MLflow 3). Databricks describes MLflow as the foundation for MLOps at scale, with over 30 million monthly downloads and more than 850 contributors (Databricks). The production footprint has not changed, and neither has the recommendation to use it as the system of record for runs, models, and traces.
The ring moves from adopt to trial for security-posture reasons rather than product reasons. CVE-2026-64849 is a critical (CVSS v3.1 9.3) unauthenticated server-side request forgery in MLflow's webhook test endpoint, affecting all versions prior to 3.15.0; because the endpoint reflects the upstream response back to the caller, a DNS-rebinding attacker can read cloud instance-metadata credentials for AWS, GCP, or Azure directly out of the server (Cloud Security Alliance). watchTowr's honeypot network observed attackers scanning and exploiting internet-exposed tracking servers within hours of the CVE's public assignment on August 17, 2026, and CISA added it to the Known Exploited Vulnerabilities catalog.
This is not a single-CVE story. Ten advisories published between April 3 and August 17, 2026 describe missing or misapplied authorization checks on MLflow endpoints, with the basic-auth plugin failing open when an endpoint is absent from its handler map (Particula). Trial means keep running it — with 3.15.0-or-later patching, network isolation, and no exposed tracking servers treated as a hard gate rather than a hardening backlog item.
Adoption Signals
- MLflow 3 explicitly unifies traditional ML, deep learning, and GenAI: the same instrumentation, registry, and monitoring path serves a training pipeline and a multi-agent RAG system (Announcing MLflow 3).
- Release cadence remains high and product-led: 3.14.0 shipped
mlflow agent setup, review queues, an evaluation-dataset UI, and a pytest integration that gates GenAI quality in CI (3.14.0 release notes); later releases added an MCP Registry and describable trace views (releases). - Managed MLflow 3 on Azure Databricks preserves core MLflow 2.x tracking concepts while adding LoggedModels and staged deployment jobs, keeping migration low-friction for existing users (Azure Databricks).
- The project itself now publishes enterprise standardization guidance covering identity and access posture, registries, evaluation criteria, and a unified observability schema (MLflow).
- LoggedModel as a first-class entity decouples the model from the run that produced it, which simplifies promotion and lineage in production pipelines (field write-up).
Risks
- Actively exploited unauthenticated SSRF. CVE-2026-64849 (CVSS 9.3) lets an unauthenticated caller drive
POST /api/2.0/mlflow/webhooks/{id}/testat internal addresses such as 169.254.169.254 and read the reflected response, yielding cloud IAM tokens and service-account keys; exploitation was observed in the wild within hours of disclosure (CSA). - The root cause is a TOCTOU gap, not a filter bug.
_validate_webhook_url()checks the destination at registration time, while the delivery code follows redirects and re-resolves hostnames without pinning the validated IP — so allowlist-style mitigations below 3.15.0 do not close it (CSA). - Authorization fails open by design. The basic-auth plugin resolves each request against a 120-entry dictionary and skips the check on a miss; only the
/mlflow/traces/prefix fails closed, and CVE-2026-71211 (7.1) coveringCreateGatewaySecrethad no recorded fixed version as of 3.15.2 (Particula). - Cross-tenant artifact reads. CVE-2026-69148 lets an authenticated user reference another user's
run_idinCreateModelVersionand then read arbitrary files from the victim's artifact directory, bypassing the experiment-level READ gate (GitHub Advisory). - Security was retrofitted, not designed in. Default MLflow deployments have no authentication, no authorization, and no isolation, so multi-tenant or shared installs need deliberate engineering before they are production-appropriate (redteams.ai).
- Legacy model-loading risk persists. CVE-2024-37058 (CVSS 8.8) allows a maliciously uploaded LangChain AgentExecutor model to execute arbitrary code when loaded, which matters wherever registry writes are not fully automated (Meterian).
Pros & Cons
Advantages
- MLflow 3 covers traditional ML, deep learning, and GenAI in one control plane, so a transformer training pipeline and a multi-agent RAG system can share the same tracking, registry, and monitoring tooling.
- The project ships rapid, substantive point releases — 3.14.0 added one-command agent instrumentation, review queues, and a pytest gate for GenAI quality in CI, and 3.16.0 added an MCP registry and customizable trace views.
- Managed MLflow 3 on Databricks preserves MLflow 2.x tracking concepts while adding LoggedModels and deployment jobs, which keeps migration cheap for teams that already standardized on the API.
Disadvantages
- CVE-2026-64849 is a critical (CVSS 9.3) unauthenticated SSRF in the webhook test endpoint affecting every release before 3.15.0, and it has been exploited in the wild for cloud metadata credential theft since public assignment on August 17, 2026.
- The basic-auth plugin authorizes by dictionary lookup and fails open on a miss, so endpoints absent from the 120-entry map are unguarded rather than denied — CVE-2026-71211 still had no recorded fixed version at 3.15.2.
- Default MLflow deployments ship with no authentication or authorization at all, so any internet-reachable tracking server is effectively a public API over experiments, artifacts, and registry state.
Recommendation
Keep MLflow 3 as the system of record for training runs, registered models, and GenAI traces — but treat the security work as a precondition this quarter, not a follow-up. Inventory every tracking server, including forgotten team instances and anything fronted by a load balancer, and confirm the running version. Anything below 3.15.0 is affected by CVE-2026-64849 and should be patched immediately; assume compromise for any instance that was internet-reachable, rotate the instance-role and service-account credentials it could reach, and review metadata-service access logs (CSA).
Remove internet exposure as a standing control. Put tracking servers behind an authenticating reverse proxy or private network, enforce IMDSv2-style metadata protections on the hosts, and restrict egress from the MLflow server so a future SSRF has nowhere useful to go. Do not rely on the bundled basic-auth plugin as an authorization boundary: it fails open for endpoints missing from its handler map, so scope trust at the network and proxy layer and keep separate instances for tenants that must not read each other's artifacts (Particula).
On the platform side, the prior guidance still holds: enforce retention policies on trace logging for chatty agents, gate promotion with evaluation criteria in CI — 3.14.0's pytest integration makes this concrete (3.14.0) — standardize autologging per language, and block manual registry writes outside automation, which also limits the malicious-model-loading path. Add MLflow to whatever process watches CISA KEV and the mlflow advisory feed; ten authorization advisories in five months means patch latency, not feature choice, is the deciding factor for moving this back to adopt.
Sources
- 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
Overview
MLflow is an open platform for the complete machine learning lifecycle, now extended in MLflow 3 for GenAI applications with tracing, prompt management, and evaluations alongside experiments and model registry (MLflow documentation).
Adopt when you want a vendor-neutral control plane for experiments, models, and GenAI traces that integrates with Databricks, Kubernetes, or self-hosted infrastructure. Pair with your inference gateway and feature store rather than replacing them.
Adoption Signals
- MLflow 3 documentation positions GenAI tracing alongside traditional run tracking.
- Databricks customers inherit managed MLflow with enterprise auth and audit patterns.
- OpenTelemetry export paths emerge for correlating MLflow traces with APM stacks.
- Community adoption remains high for sklearn, PyTorch, and LangChain instrumentation.
Risks
- Unbounded trace logging for chatty agents increases storage cost quickly.
- Promoting models without evaluation gates reintroduces manual registry mistakes.
- Multi-tenant deployments need auth plugins; default installs are not production-ready.
- Overlapping LangSmith or vendor tracing can duplicate telemetry without standards.
Pros & Cons
Advantages
- Unified tracking for classical ML and GenAI traces under one OSS project reduces tool sprawl.
- Model Registry supports stage promotions, aliases, and governance hooks enterprises expect.
- MLflow 3 expands GenAI evaluation, prompt registry, and tracing aligned with agent workloads.
Disadvantages
- Self-hosted deployments need DBA and storage planning for artifact volumes and trace retention.
- Feature depth for LLMOps still trails specialized vendors in advanced eval and guardrail UX.
- Teams must define naming, tagging, and permission conventions or metadata becomes unsearchable.
Recommendation
Adopt MLflow 3 as the system of record for training runs, registered models, and GenAI traces, with retention policies and promotion workflows enforced in CI. Standardize autologging libraries per language and block manual registry writes outside automation.