Can An Unpatched MLflow Server Expose Cloud Credentials And Model Weights?

August 18, 2026

MLflow flaws can expose cloud metadata, private model artifacts, and dataset lineage. Here is what is confirmed and what operators should do now.

Yes. According to three GitHub-reviewed security advisories, an MLflow server running a version before 3.15.0 can expose more than experiment charts. One critical flaw can let an unauthenticated attacker make a reachable tracking server read cloud-metadata or internal-service responses. A separate high-severity authorization flaw can let an authenticated user read another user's private run artifacts, including model weights, training samples, or evaluation reports. A third flaw can let an authenticated user corrupt another run's dataset-lineage records.

The immediate action is straightforward: inventory every MLflow tracking server, upgrade to MLflow 3.15.0 or later, remove direct internet exposure, verify authentication and authorization, and investigate whether webhook, artifact, or lineage endpoints were abused. MLflow 3.15.1 is the current patch release in the official GitHub release feed reviewed for this article.

This is not evidence that every MLflow deployment was breached. The advisories document reproducible vulnerabilities, not confirmed mass exploitation. But the combination matters because an AI tracking server often sits close to cloud credentials, model artifacts, datasets, evaluation results, and internal services.

What Is Confirmed

GitHub's Advisory Database published three reviewed MLflow entries on August 17, 2026. All three identify versions before 3.15.0 as affected and 3.15.0 as the first patched version.

The most serious is CVE-2026-64849, a critical 9.3 server-side request forgery vulnerability in MLflow's webhook delivery path. The advisory says the default open-source tracking server exposes model-registry webhook endpoints without authentication. Although MLflow validated the original webhook URL, it did not safely bind that validation to the actual network connection or revalidate redirect destinations.

That gap created two paths:

• a 302 redirect could make MLflow fetch an internal URL and return its response body through the webhook test endpoint; and
• a 307 or 308 redirect could preserve the POST method and send a blind write to an internal service.

The advisory says a reachable vulnerable server could be made to query loopback addresses, private-network services, or cloud instance-metadata endpoints. Its proof of concept retrieved an internal secret from a server running MLflow 3.13.0. The fix adds connection-time peer-IP validation so redirects and DNS changes are checked when the connection is actually made.

The second issue, CVE-2026-69148, is rated high at 7.1. It applies to permission-restricted deployments and requires an authenticated user who can create or manage a registered model. The advisory says MLflow validated that a model-version source path belonged to a referenced run but failed to verify that the caller had permission to read that run.

An attacker could therefore create a model version that points to another user's artifact directory and then use the model-version artifact handler to read files that the normal run-artifact endpoint would deny. The advisory specifically identifies model weights, training-data samples, and evaluation reports as examples of exposed content.

The third issue, CVE-2026-69146, is rated moderate at 6.5. In a deployment using MLflow's built-in basic-auth app, the LogInputs endpoint was missing the per-run authorization check applied to other write endpoints. Any authenticated user could add dataset records to another user's run. That does not expose the underlying dataset by itself, but it can corrupt provenance and audit evidence about what data a model used.

MLflow released version 3.15.0 on July 31 and version 3.15.1 on August 3. The latter is a small patch release and remains above the affected range identified by all three advisories.

What Is Still Unclear

The reviewed sources do not say that attackers exploited these flaws in the wild. They do not estimate how many vulnerable MLflow servers remain reachable, how many use the default unauthenticated setup, or how many multi-user deployments rely on the affected authorization paths.

They also do not prove that real cloud credentials, production model weights, or regulated training data were stolen. Those are technically credible impact paths documented by the advisories, not confirmed victim counts.

The timing deserves precision. The critical advisory credits a private report on June 12 and an independent public report on June 26. MLflow shipped the fix in 3.15.0 on July 31. The project-level advisories were published in early August, then entered GitHub's reviewed public advisory database on August 17. The vulnerabilities are therefore newly consolidated and reviewed in a major public feed, but they were not all discovered today.

It is also unclear whether every managed service that includes MLflow uses the same vulnerable routes, default settings, network placement, artifact store, or authentication plugin. A hosted platform may patch or isolate its service independently. Operators should ask the provider for an affected-version statement instead of assuming that the open-source default maps exactly to the hosted environment.

Why An MLflow Server Can Become A High-Value Privacy Boundary

MLflow is not merely a dashboard. In a working AI environment, it can connect several sensitive layers:

• experiment parameters and metrics;
• prompts, traces, and evaluation results;
• registered models and model versions;
• artifact stores containing weights, reports, samples, or attachments;
• cloud storage and presigned download paths;
• webhooks that reach other services; and
• identity and authorization rules shared by multiple users or teams.

That makes the tracking server a junction. A flaw in one route can cross into another trust zone even when the MLflow database does not directly contain the most valuable secret.

The critical webhook issue is a good example. Server-side request forgery changes who makes the request. An external attacker does not need direct network access to a private metadata endpoint if the vulnerable MLflow server can reach it and return the result. The server becomes a proxy through the firewall.

The artifact issue crosses a different boundary: identity. The attacker is already a valid user, but the software fails to enforce the difference between “I may manage this model” and “I may read that other user's run.” Authentication alone does not solve that problem. The authorization check must follow every reference from the model record to the source artifact.

The lineage issue crosses the integrity boundary. Privacy reviews often focus on whether data can be read. AI governance also depends on whether the record of which dataset trained which model can be trusted. A fake dataset entry can create false evidence, derail an investigation, or make a reproducibility record unreliable without modifying the model itself.

Are Internet-Facing MLflow Servers At Greater Risk?

Yes. Internet exposure materially increases the attack surface for the critical webhook flaw because the advisory says the default endpoint can be reached without authentication. A network control that prevents untrusted clients from reaching the server can block that direct path even before the application is upgraded.

That is a compensating control, not a substitute for patching. A server reachable only through a VPN, private ingress, identity-aware proxy, or internal network can still be attacked by a compromised internal account, workstation, workload, or connector. The authorization flaws also assume authenticated access, so they remain relevant in multi-user private deployments.

Do not expose mlflow server directly to the public internet simply because the interface appears administrative or the database is small. Put a deliberate access layer in front of it, restrict who and what can reach it, and separate its network identity from services that hold broader cloud authority.

What Operators Should Do Now

Use the PATCH response sequence to reduce both immediate and residual risk.

P — Pin The Version And Prove The Upgrade

Find the running version in every environment, including developer machines, notebooks, containers, Kubernetes workloads, CI jobs, and managed images. Upgrade anything below 3.15.0. Prefer the latest supported 3.15.x or newer release after checking compatibility.

Do not stop at a dependency file. Verify the version in the running process and image. Old pods, cached containers, shadow servers, and forgotten test environments can survive after a repository is updated.

A — Authenticate, Authorize, And Reduce Reachability

Require authentication at the application or trusted ingress layer. Remove direct public exposure. Restrict ingress to the smallest necessary user and workload set. Treat “valid account” and “permission to this resource” as separate checks.

Review default permissions for experiments, registered models, artifacts, and workspaces. A shared account weakens attribution. Broad read defaults can turn a technical authorization bypass into ordinary overexposure even after the specific flaw is fixed.

T — Test The Network And Artifact Boundaries

Map what the MLflow server can reach. Pay special attention to cloud metadata, container control sockets, internal admin panels, databases, search clusters, and services with unauthenticated internal endpoints. Block unnecessary egress and use cloud controls that harden metadata access.

Confirm that an ordinary test user cannot read another user's run artifacts by creating a model-version reference. Confirm that the same user cannot add dataset inputs to a run they do not control. Perform these checks in an isolated test environment; do not replay public proofs of concept against systems you do not own or have permission to test.

C — Check Logs, Artifacts, And Credentials

Review application, reverse-proxy, load-balancer, identity, cloud-metadata, and network-flow logs for suspicious webhook creation or testing, unusual redirects, artifact reads, model-version creation, and cross-user lineage changes.

Look for outbound connections from MLflow to loopback, link-local, private, or unexpected public destinations. A request to 169.254.169.254, an unfamiliar redirect host, or an internal administration path deserves immediate investigation.

If the server could reach cloud metadata or other credential endpoints, rotate potentially exposed credentials and review their use. Patching stops the known route; it does not invalidate a token that may already have been copied.

H — Harden The Architecture After The Incident Window

Separate MLflow's service identity from powerful production roles. Give the server only the cloud and artifact permissions it actually needs. Segment artifact storage by environment or team when practical. Keep backups and audit logs outside the authority of the application account.

Add upgrade ownership, an asset inventory, and a defined response window for security advisories. AI infrastructure changes quickly, but a fast feature cadence does not reduce the need for ordinary patch, identity, egress, and logging discipline.

How To Investigate Without Destroying Evidence

Start by recording the running versions, container digests, configuration, ingress paths, authentication mode, artifact-store locations, and service identities. Preserve relevant logs before restarting or replacing workloads if your retention window is short.

Then build a timeline:

1. When did each affected server first run a version below 3.15.0?
2. When was it reachable, and from which networks?
3. Was the webhook API enabled and backed by a SQL store?
4. Were unexpected webhooks created or tested?
5. Did the server contact link-local, loopback, private, or unfamiliar destinations?
6. Did users create model versions referencing runs they did not own?
7. Were artifact downloads or dataset-lineage writes inconsistent with normal work?
8. Which credentials and internal services were reachable from the server at those times?

Avoid treating the absence of one MLflow log entry as proof that nothing happened. Reverse proxies, cloud audit logs, artifact-store access logs, identity-provider records, and network telemetry may preserve evidence that the application does not.

Does Upgrading Delete Exposed Data Or Revoke Stolen Credentials?

No. Upgrading changes the vulnerable code path. It does not erase an artifact that was downloaded, repair every falsified lineage record, or revoke credentials obtained from a metadata endpoint.

That is why remediation has three separate parts:

• close the vulnerability;
• determine what the server could reach and what activity occurred; and
• rotate or repair anything that may have crossed the boundary.

If dataset lineage is used for compliance, model cards, reproducibility, or customer evidence, compare affected records with an independent source of truth. A clean current screen does not prove that historical metadata was never altered.

Does Self-Hosting Automatically Make AI Data Private?

No. Self-hosting can give an organization more control over storage, networking, identity, logging, and model selection. It also transfers responsibility for patching, configuration, secrets, egress, backups, and incident response to the operator.

A service can run on infrastructure you control and still leak data through an exposed endpoint, excessive cloud permission, weak authorization, vulnerable dependency, public artifact bucket, or unmonitored outbound request. “Local,” “private cloud,” and “self-hosted” describe deployment choices. They do not certify the entire data path.

The better question is: which components receive the data, where do they store it, what can they reach, who can authorize access, and how quickly can you detect and revoke a failure?

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for chat, files, web search, images, voice, and video. It is an alternative for people who want useful AI workflows without operating their own model-serving, tracking, registry, and evaluation infrastructure.

That does not make OpenVeil an MLflow security product. OpenVeil does not patch an MLflow server, scan it for these CVEs, secure its cloud role, rotate its credentials, validate its lineage records, or protect data sent to an unrelated MLflow deployment.

OpenVeil also is not fully offline or anonymous. Active requests are processed by OpenVeil and the necessary providers. Its documented privacy boundary is narrower: normal chat history stays in the browser rather than a normal server-side chat-history record, and prompts, uploads, media, and outputs are not used to train foundation models. Users should still avoid entering secrets they do not need to share and should evaluate each active workflow's provider and retention boundary.

The practical choice is not “hosted equals unsafe” or “self-hosted equals private.” It is whether the product's documented data path matches your needs and whether you want to operate the surrounding security controls yourself.

Frequently Asked Questions

Which MLflow versions are affected?

All three reviewed advisories list versions before 3.15.0 as affected and 3.15.0 as patched. Check the running version, not only the declared dependency. MLflow 3.15.1 is also above the affected range.

Can the critical MLflow flaw expose AWS credentials?

Potentially. The advisory says the server-side request forgery can read cloud instance-metadata responses, including the type of IAM credential path used in its example. Actual exposure depends on the cloud, metadata configuration, network reachability, and role attached to the server. No reviewed source cited here confirms theft from a real victim.

Does the model-weight flaw require authentication?

Yes. The high-severity artifact issue requires an authenticated user who can create or manage a registered model. It matters in multi-user deployments where another user's experiment or run artifacts are supposed to be private.

Is basic authentication enough to protect MLflow?

No. Authentication establishes identity. The two cross-user flaws involve missing resource-level authorization after identity is established. Use authentication, least privilege, network controls, and patched software together.

Should I rotate cloud credentials after upgrading?

Rotate any credential that the vulnerable server could have exposed or that logs suggest may have been accessed. When evidence is incomplete and the credential has meaningful authority, rotation is usually safer than assuming it remained secret.

Was MLflow 3.15.0 released because of these vulnerabilities?

The reviewed advisories identify 3.15.0 as the first patched version and link to the release. The public release notes emphasize many features and bug fixes rather than presenting the release as a dedicated security bulletin. The advisories are the more precise source for the affected and patched ranges.

The Bottom Line

An unpatched MLflow server can sit at the intersection of cloud identity, internal networking, private model artifacts, and AI governance records. The reviewed advisories show three different failure modes: crossing a network boundary without authentication, crossing a user's artifact boundary with a valid account, and crossing a run's integrity boundary to alter lineage.

Upgrade to 3.15.0 or later, reduce reachability, verify per-resource permissions, inspect logs and artifact access, and rotate credentials that may have been exposed. Do not equate a documented vulnerability with a confirmed breach—but do not wait for a victim count before fixing a critical route into cloud metadata and internal services.