Quick take: CISA added CVE-2026-64849, an MLflow server-side request forgery issue, to its Known Exploited Vulnerabilities catalog on August 19, 2026. For small teams experimenting with self-hosted AI infrastructure, the important point is not just “patch MLflow.” It is to stop treating internal ML dashboards, registries, webhooks, and cloud metadata access as harmless development plumbing.
MLflow is widely used to track machine-learning runs, register models, and coordinate model workflows. The MLflow Tracking Server documentation describes it as a stand-alone HTTP server for tracking runs and experiments, while the Model Registry workflow helps teams register models, manage versions, and organize deployment aliases. That is useful operational infrastructure. It is also exactly the kind of system that can end up connected to cloud credentials, artifact stores, internal networks, model registries, and automation hooks.
The latest KEV entry is a practical warning for small businesses that have started building with AI agents, machine-learning pipelines, internal model registries, or vendor-provided AI automation. If an AI tool can make outbound calls, trigger webhooks, move model artifacts, or talk to internal services, it belongs in the security inventory.
What happened with CVE-2026-64849?
According to NVD’s CVE-2026-64849 entry, the issue affected MLflow before version 3.15.0. The description says a webhook test endpoint could call URL validation on the original URL while delivery followed redirects and re-resolved hostnames without pinning the validated address. In plain English: MLflow could be convinced to make a server-side request to a place the attacker should not be able to reach directly.
The GitHub security advisory GHSA-7gwp-5pfp-969j describes this as an SSRF issue in webhook delivery. It highlights redirect-following and DNS rebinding as bypass paths. In one scenario, a public HTTPS endpoint can pass URL checks and then redirect MLflow toward an internal or cloud metadata URL. The advisory rates the issue as critical and ties it to CWE-918, server-side request forgery.
CISA’s KEV catalog entry for the vulnerability lists MLflow Server-Side Request Forgery, date added August 19, 2026, and a due date of September 2, 2026 for covered organizations. The catalog’s required action is to apply mitigations according to vendor instructions and follow CISA’s risk-based remediation guidance.
Why small businesses should care even if they are not federal agencies
CISA KEV deadlines are written for federal civilian executive branch agencies, but the catalog is useful far beyond government. A KEV listing means exploitation is known, not theoretical. For a small company, that can help decide which security updates move to the front of the line.
MLflow is not a consumer app sitting on an employee laptop. It often sits near higher-value technical assets: cloud buckets, experiment metadata, model artifacts, deployment credentials, CI/CD systems, and internal dashboards. A small team may expose it during a prototype, keep default settings longer than intended, or wire it into automation before applying the same controls used for production web apps.
That is why this issue matters even for companies that do not think of themselves as “AI companies.” A marketing agency using AI scoring experiments, a SaaS startup fine-tuning support workflows, or a data team testing model registry automation can all accumulate ML infrastructure. The danger is that the security program still treats it as a lab project.
What SSRF means in AI infrastructure
Server-side request forgery happens when an attacker can make a server fetch a URL of the attacker’s choosing. The attacker may not be able to reach your internal network from the internet, but your server can. If the vulnerable server follows redirects, resolves hostnames at the wrong time, or returns internal responses to the caller, the attacker may use it as a proxy into private resources.
In AI and ML infrastructure, SSRF is especially uncomfortable because these systems frequently need broad connectivity. They may download model artifacts, send webhooks, contact feature stores, read object storage, and run near cloud roles. The risk is not limited to one database query. It can become a path to metadata services, IAM credentials, private admin panels, experiment data, and model supply-chain systems.
The MLflow advisory is a good example of a subtle engineering failure. The original guard could resolve a hostname and reject private IPs, but the actual request path could re-resolve or follow redirects. The fix described in MLflow pull request #24258 validates the peer IP of the actual connected socket after connect and before HTTP or TLS data is exchanged. That matters because security checks need to cover the connection that actually happens, not just the URL that looked safe earlier.
Who is most exposed?
Start with three questions:
- Do you run MLflow yourself? If you use a hosted managed platform, your vendor should address platform-level remediation. If you run open-source MLflow on a VM, Kubernetes cluster, lab server, or internal workstation, you own the patching and exposure decisions.
- Is the tracking server reachable beyond localhost? The MLflow server documentation shows local defaults, but team deployments often move toward remote access. Anything bound broadly or placed behind a simple reverse proxy deserves a fresh review.
- Can the MLflow host reach sensitive services? The blast radius is different when the server can reach cloud metadata, private subnets, artifact buckets, databases, or internal admin APIs.
Small teams should pay particular attention to “temporary” AI infrastructure. The forgotten demo server, the test GPU box, and the shared experiment VM can be more exposed than the official production app because nobody thinks of them as production.
Immediate checklist for MLflow teams
1. Confirm whether MLflow is in your environment
Search infrastructure manifests, Docker images, VM process lists, notebooks, CI jobs, and internal documentation for MLflow. Do not rely only on the security tool inventory; ML tooling is often installed by data teams before it is added to the central asset register.
2. Check the installed version
NVD states that CVE-2026-64849 is fixed in version 3.15.0. If you self-host MLflow, verify the actual package version running in the service environment, not just a developer laptop. Container tags, base images, and long-running virtual environments can lag behind.
3. Patch or redeploy from a fixed release
Plan the update like an infrastructure change: snapshot or back up the backend store, test the service start, confirm tracking and model registry workflows still work, and redeploy with a fixed version. The MLflow 3.15.0 release is the key version reference for this issue.
4. Restrict network exposure
If the server does not need public access, do not give it public access. Put it behind VPN, SSO, a private network, or a zero-trust access layer. Restrict inbound access to the teams and automation that actually use it. Do not assume a randomly named internal tool is safe just because it is obscure.
5. Reduce outbound reach
SSRF becomes much worse when a compromised service can reach everything. Use egress controls, firewall rules, cloud security groups, and metadata-service protections to limit where an MLflow server can connect. If it only needs a database, an artifact bucket, and a few approved endpoints, do not let it browse private networks freely.
6. Protect cloud metadata and credentials
Review the instance role or workload identity attached to the MLflow host. Give it the least privilege needed. Disable unnecessary metadata access where possible, prefer metadata-service protections offered by your cloud provider, and rotate credentials if there is any sign that the service was exposed during the vulnerable window.
7. Audit webhook usage
List configured webhooks and confirm where they point. Unexpected webhook destinations should be investigated. Even legitimate webhook destinations should be reviewed: production automation, Slack alerts, CI/CD hooks, and internal APIs should not be loosely reachable from experimental infrastructure.
How this fits into CISA’s risk-based patching model
CISA’s BOD 26-04 guidance emphasizes risk-based remediation using factors such as public exposure, KEV status, exploit automation, and technical impact. That model is useful for small businesses because it avoids the impossible demand to patch every CVE with equal urgency.
For CVE-2026-64849, a practical priority score might look like this:
| Condition | Priority | Action |
|---|---|---|
| Internet-reachable MLflow server, vulnerable version, cloud role attached | Critical | Patch immediately, restrict access, review logs and credentials |
| Internal-only server but reachable by many users or VPN clients | High | Patch quickly and audit webhook destinations |
| Local development instance only | Medium | Update base environments and prevent accidental exposure |
| No MLflow use confirmed | Informational | Record the check and monitor future AI infrastructure additions |
Signals to check after patching
After updating, do not stop at “the service started.” Review reverse proxy logs, MLflow access logs, webhook configuration changes, unusual webhook tests, unexpected outbound requests, and cloud audit logs for metadata or credential use. If the MLflow host had broad cloud permissions and was reachable by untrusted users, treat it like a real incident review rather than a routine package bump.
Good evidence to collect includes the previous MLflow version, the patched version, exposure path, authentication controls, firewall rules, webhook list, cloud role permissions, and the date the service was fixed. This turns a one-off patch into an asset-management improvement.
How to prevent the next AI infrastructure surprise
The deeper lesson is that AI infrastructure needs the same guardrails as other production systems. Add ML and AI tools to your normal software inventory. Require ownership for model registries, vector databases, agent gateways, evaluation dashboards, notebooks, and workflow automations. Place them behind the same access-control and logging standards used for customer-facing systems.
For small teams, the most useful rule is simple: if a tool can store model artifacts, execute automation, send webhooks, or reach cloud resources, it is not “just a dev tool.” Give it an owner, a patch schedule, network boundaries, and an incident path.
FAQ
Is this only a problem for companies that use MLflow?
The specific CVE is MLflow-specific, but the pattern is broader. AI tooling often introduces new web servers, APIs, background jobs, and webhook systems. Those systems need inventory, patching, authentication, and egress controls.
Is a localhost-only MLflow server affected?
A localhost-only instance has much lower exposure than a remotely reachable service. Still, teams should patch local environments because notebooks, tunnels, shared workstations, and container defaults can change exposure over time.
Should every small business patch MLflow immediately?
If you run MLflow before 3.15.0, especially on a shared or reachable server, yes. If you do not use MLflow, record that finding and use this as a prompt to inventory other AI infrastructure.
Does patching replace network controls?
No. Patching closes the known flaw, but SSRF-class issues are easier to contain when outbound access is limited, metadata endpoints are protected, and internal services are not broadly reachable from every tool server.
Final verdict
CVE-2026-64849 is not just another patch note. It is a clear example of how AI infrastructure can create paths between public-facing or semi-public tools and sensitive internal resources. For CyberTrendLab readers, the move is straightforward: confirm whether MLflow is present, patch to a fixed version, reduce exposure, audit webhooks, and add AI infrastructure to the same risk-based patching process used for core business systems.
For more practical security planning, read CyberTrendLab’s guides on AI agent audit logs, AI data leakage prevention, and MCP security for AI agent tool access.
