MLflow SSRF to Cloud Credentials: What Your Cloud Pentest Must Catch

Your ML platform owner confirms that MLflow has been upgraded. The tracking server no longer appears vulnerable, the change ticket is closed, and the team wants to move on. Then the CISO asks the question that determines whether the organization is actually safe: if that server had been abused before the patch, what cloud authority could an attacker have obtained, and would the evidence show it?

That is the business significance of the MLflow SSRF vulnerability tracked as CVE-2026-64849. The issue affected MLflow versions before 3.15.0 and could let an unauthenticated attacker make a reachable tracking server request internal resources, including cloud instance metadata. CISA's Known Exploited Vulnerabilities catalog now treats the flaw as evidence of exploitation in the wild, so this is no longer a theoretical software defect. It is a current cloud-identity validation problem.

Patching is urgent, but it answers only whether the known entry point is closed. Leadership still needs proof that exposed ML infrastructure, metadata controls, workload identities, permissions, monitoring, and credential containment work together. That proof belongs in a cloud and AI infrastructure penetration test.

Why the MLflow SSRF alert changes the buyer decision

The reviewed GitHub security advisory for CVE-2026-64849 describes a critical unauthenticated server-side request forgery condition in the model-registry webhook flow. The advisory lists versions before 3.15.0 as affected and 3.15.0 as patched. It explains that a default MLflow tracking server could expose webhook functionality without authentication, follow a destination change, and return the upstream response to the requester. The result could include responses from internal services or a cloud metadata endpoint.

CISA's KEV status adds the operational trigger. KEV inclusion means organizations should treat the vulnerability as exploited, not merely exploitable. For a buyer, the immediate decision is therefore broader than “Did we upgrade?” It is:

• Was an affected MLflow service reachable from the internet, an untrusted network, a partner connection, or another compromised workload?
• Could the MLflow runtime reach a metadata service or sensitive internal control plane?
• Did the attached workload identity have permissions beyond what experiment tracking and model management required?
• Could short-lived credentials have been used from another location before they expired or were revoked?
• Do cloud, load balancer, application, DNS, identity, and data-plane logs preserve enough evidence to answer those questions?

A scoped cloud penetration test for AWS, Azure, or Google Cloud should validate that full chain under agreed safeguards. This is materially different from running a version scanner. A scanner can flag an outdated package. It cannot prove the effective authority of a workload identity, whether a metadata defense holds through the real network path, or whether monitoring reconstructs a controlled credential-use scenario.

The MLflow SSRF cloud credential attack chain, without the exploit recipe

The technical mechanics matter because they connect an application flaw to cloud impact, but leadership does not need a payload tutorial. The relevant chain has five business control points:

1. Reachability: an attacker or compromised workload can send requests to an affected MLflow tracking service.
2. Server-side request behavior: the service can be induced to make a request beyond the intended external destination.
3. Metadata access: the runtime can reach a cloud instance metadata service or another internal identity endpoint.
4. Credential value: the attached role, managed identity, or service account has permissions that create material impact.
5. Credential use: the temporary credential can be used to read data, obtain secrets, modify infrastructure, access model artifacts, or move into another environment, depending on its actual policy.

Each link is independently preventable. Strong ingress restrictions can stop the first. Correct SSRF handling closes the second. Metadata-service hardening and workload network controls reduce the third. Least privilege limits the fourth. Session restrictions, organization policies, anomaly detection, and rapid revocation constrain the fifth.

The dangerous assumption is that one control makes the rest unnecessary. A private MLflow deployment can still be reached from a compromised notebook, CI runner, VPN-connected endpoint, or adjacent workload. A patched application can coexist with another server-side request primitive. A modern metadata protocol can reduce common SSRF paths without making an over-privileged role acceptable. Least privilege can reduce blast radius without answering whether credentials were already used.

This is why the test should model the chain rather than confirm a single configuration. Our guide to AI agent identity security in a cloud pentest addresses the same underlying principle from another angle: authentication is not enough; effective authority and enforceable boundaries are what matter. The MLflow case applies that principle to an AI/ML platform service and its runtime identity.

What an MLflow SSRF cloud pentest must validate

The right scope follows the workload from exposure to business impact. It should be bounded by rules of engagement, approved test accounts, agreed cloud regions and environments, non-destructive proof, and explicit stop conditions. Production validation may be possible, but sensitive credential-use tests are often safer in a production-equivalent environment with a deliberately limited role and monitored canary resources.

1. Find the deployments the patch project may have missed

ML tooling often spreads outside the standard application inventory. A platform team may maintain production tracking, while data scientists run local or shared instances, CI creates temporary containers, and old images remain in registries or templates. Scope should reconcile cloud assets, Kubernetes workloads, container images, virtual machines, exposed ports, DNS records, load balancers, infrastructure-as-code, and software inventories. The objective is not an exhaustive cloud audit. It is confidence that no affected or equivalently exposed MLflow path remains.

2. Test the boundary, not only the public hostname

An internet-facing instance deserves immediate priority, but “internal only” is not a complete risk decision. Testers should assess approved paths from representative trust zones: public ingress, corporate networks, build systems, notebooks, cluster workloads, and other services that can reach the tracking server. The evidence should distinguish unreachable, authenticated, authorized, and merely undocumented paths.

Where broader external fixes have already been deployed, use a closure approach similar to post-patch external penetration testing: confirm that the known path is closed, alternate paths do not recreate the exposure, and the result is captured in retest evidence rather than inferred from a change ticket.

3. Prove metadata and egress controls with safe negatives

The test should verify that the workload cannot use application-mediated requests to reach prohibited internal destinations. It should cover destination validation at every redirect or resolution step, proxy behavior, DNS controls, egress restrictions, and the actual network namespace used by the MLflow service. A configuration review alone can miss differences between host, container, sidecar, node, and service-mesh paths.

Provider controls must be evaluated in context. AWS customers should validate their use of current metadata protections and whether the runtime truly requires metadata access. Azure and Google Cloud customers should test the equivalent managed-identity or metadata path, including required request protections and workload network boundaries. The safe outcome is not “the endpoint exists.” It is “the application cannot turn untrusted input into credential retrieval, and any permitted metadata access serves a narrowly scoped identity.”

4. Calculate what the workload identity can really do

The severity of cloud credential exposure is determined by effective permissions, not by the credential's name. A role called mlflow-readonly may inherit permissions through managed policies, groups, resource policies, cross-account trusts, key policies, or service-specific grants. Testing should map reachable storage, model registries, artifact stores, secrets, databases, queues, deployment pipelines, and role-assumption paths.

Prioritize actions that change business impact: access to customer or training data, model artifacts, signing or deployment systems, production secrets, tenant environments, billing resources, logging controls, and identity administration. Do not perform destructive actions. Use canary resources, approved test principals, simulation where necessary, and the minimum proof needed to establish impact.

5. Validate detection, rotation, and retest

A mature test includes incident evidence. Can the security team identify an unusual request to the ML platform, a request toward a prohibited destination, a metadata credential event where the provider exposes it, and API activity by the workload identity from an unexpected source? Can responders revoke the role session, rotate dependent secrets, isolate the workload, and preserve the logs required for review?

The answer should become a timed, evidence-backed result. “Credentials expire quickly” is not enough if the token remains valid long enough to obtain persistent secrets or create another access path. “CloudTrail is enabled” is not enough if logs are delayed, incomplete, mutable from the compromised role, or disconnected from MLflow and network telemetry.

Patch, investigate, or pentest: choose the right response

These actions are complementary, but the order changes with exposure. The following decision model helps prevent a patch-only response when incident handling is warranted.

Exact duration and cost depend on the number of cloud accounts, clusters, MLflow deployments, identity paths, environments, and evidence sources. A narrowly scoped test of one deployment and one cloud account is different from a multi-account AI platform review. Buyers should request a fixed scope that names the assets, trust zones, identities, sensitive resources, test constraints, evidence outputs, and retest conditions before work begins.

A sanitized scenario: the patch closes the bug, but not the exposure

Consider a hypothetical SaaS company using MLflow for experiments and model registration. The tracking server sits behind a reverse proxy. Engineers believe it is private, but an old load balancer rule exposes a direct service path. The MLflow virtual machine has a workload role used to write artifacts to object storage. Over time, that role also gained read access to a shared secrets path and permission to invoke a deployment function.

The team upgrades MLflow to 3.15.0 and closes the vulnerability ticket. A controlled assessment then identifies four separate assurance gaps: the direct route bypassed the intended identity layer; the runtime could reach instance metadata; the role's effective authority exceeded artifact storage; and monitoring did not correlate reverse-proxy, application, identity, and cloud API activity.

No destructive action is needed to prove the business risk. The testers use approved canary resources and a restricted test identity to show that the control chain would have permitted access beyond the MLflow service's purpose. Remediation removes the direct route, enforces authentication, restricts egress and metadata use, replaces the broad role, protects logs, and adds detections for abnormal role use. Retesting proves both that prohibited paths fail and that normal model-tracking operations still work.

The lesson is not that every MLflow deployment leads to cloud compromise. It is that a reachable SSRF becomes materially dangerous when architecture and IAM let a server-side request cross from the application plane into the identity plane. Only environment-specific validation can establish whether that chain exists.

Framework mapping for evidence and governance

Frameworks help organize the test and communicate results. They do not prove that a specific deployment is secure.

• MITRE ATT&CK T1552.005, Cloud Instance Metadata API: maps the credential-access objective when an adversary attempts to obtain cloud credentials from an instance metadata service. Evidence should cover metadata reachability, identity value, observed or simulated credential use, and containment.
• NIST SP 800-115: supports a planned technical assessment with rules of engagement, testing methods, analysis, and reporting. Use it to structure a controlled, authorized test rather than an improvised production experiment.
• CIS Controls v8: relevant safeguards span enterprise asset inventory, secure configuration, account and access control management, vulnerability management, audit log management, network monitoring and defense, and incident response. Map findings to the specific safeguards your organization implements.
• OWASP LLM03:2025, Supply Chain: the ML platform and its dependencies are part of the AI system supply chain. Inventory, version governance, trusted sources, patching, and validation should include MLOps services, not only the model and application.
• OWASP LLM06:2025, Excessive Agency: this mapping applies where an AI or ML workflow is given excessive functionality or permissions. An over-privileged runtime role amplifies the impact of an application-layer failure even if no autonomous agent is involved.
• OWASP ASI08, Cascading Failures: a defect in one component can propagate into identity, storage, secrets, deployment, and downstream cloud services. The pentest should identify where the cascade stops and where it does not.
• NIST AI RMF: use GOVERN to assign ownership for AI infrastructure and supply-chain risk, MAP to identify deployment context and affected resources, MEASURE to validate controls and exposure, and MANAGE to prioritize remediation, monitoring, and acceptance decisions.

For teams using protocol-connected AI tools as well as MLOps infrastructure, MCP security testing before production addresses a different but adjacent trust boundary: tool discovery, invocation, user context, and downstream authorization. It should be included only when MCP is actually part of the architecture.

What leadership should decide now?

Leadership should leave the review with named decisions, not a generic instruction to “harden the cloud.”

1. Exposure decision: Is any affected or historically affected MLflow deployment reachable from an untrusted path? Who owns the definitive inventory?
2. Incident threshold: Which evidence triggers credential revocation, secret rotation, workload isolation, forensic preservation, customer assessment, or regulatory counsel?
3. Identity decision: What is the maximum business impact of the MLflow runtime identity today, and which permissions can be removed without breaking operations?
4. Architecture decision: Does the workload need metadata access at all? Which egress and destination controls prevent application requests from reaching identity endpoints and internal administration services?
5. Assurance decision: Will the organization accept a patch ticket, or require independent proof across ingress, SSRF defenses, metadata, IAM, logging, containment, and retest?
6. Change trigger: Which events require retesting: a new MLflow version, changed webhook behavior, new cloud role, new artifact store, network redesign, new cluster, or production launch?

The strongest approval statement is specific: affected deployments are patched or removed; no unintended route reaches the service; prohibited destinations are blocked; workload permissions are limited to the approved ML purpose; suspicious identity use is detectable; revocation works within the agreed containment objective; and retesting shows that normal operations continue.

Turn the MLflow alert into defensible cloud evidence.

CVE-2026-64849 is a useful forcing event because it connects three programs that are often reviewed separately: vulnerability management, AI/ML platform security, and cloud IAM. Treating it only as a package upgrade can leave the most important question unanswered: could the workload have converted a server-side request into usable cloud authority?

Start by restricting exposure and upgrading affected MLflow deployments to the fixed release identified by the vendor advisory. Preserve relevant evidence before logs expire. Identify the workload identity and its effective permissions. Then validate the full chain with controlled, non-destructive tests and produce an evidence package leadership, engineering, incident response, and auditors can use.

Pentest Testing Corp can scope a combined cloud and AI infrastructure assessment around the MLflow deployment, its reachable trust zones, metadata controls, workload identities, sensitive cloud resources, logging, and containment process. Book a cloud penetration test to verify that the patch closed the entry point and that the surrounding architecture limits the next one.