A critical vulnerability in MLflow has moved from responsible disclosure into active-exploitation territory, putting organisations running older releases of the widely used AI engineering platform under pressure to patch systems that can sit unusually close to cloud services, internal networks, models, and development data. MLflow fixed CVE-2026-64849 in version 3.15.0.

The vulnerability is a form of server-side request forgery, or SSRF, affecting MLflow’s model-registry webhook functionality. Under vulnerable configurations, an attacker able to reach the service could cause the MLflow server to request resources elsewhere and return information from internal or cloud-network locations that should not ordinarily be exposed directly.

The flaw affects versions earlier than 3.15.0 and has received a critical severity rating. Its significance increased when the US Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalogue, which is used widely by security teams as a prioritisation signal because inclusion requires evidence that exploitation has occurred.

The mandatory remediation deadlines attached to the catalogue apply directly to US federal civilian agencies rather than European companies, but the underlying evidence of exploitation is relevant everywhere the software is deployed. A vulnerability that has moved beyond a theoretical proof of concept should generally compete more strongly for limited patching resources than one whose practical use remains unknown.

AI infrastructure inherits ordinary software risk

The affected platform sits in the machine-learning engineering stack rather than inside an AI model. MLflow is used for work including experiment tracking, model management, evaluation, and other development processes, leaving installations potentially connected to object storage, databases, cloud APIs, source data, and internal applications.

That position can make an otherwise familiar web-security weakness particularly consequential. A server that is legitimately allowed to communicate with internal services may be trusted by network controls that would reject a request coming directly from an unknown user on the internet.

Under the vulnerable behaviour, MLflow checked the original destination supplied to the webhook mechanism but did not adequately protect subsequent redirects, allowing the request path to move towards addresses that should have been excluded. Version 3.15.0 changes the connection behaviour so that the destination actually reached is checked more robustly.

The appropriate response is therefore to upgrade rather than relying on configuration changes intended to block only the example attack paths disclosed by researchers. Organisations should also establish whether MLflow servers are reachable from untrusted networks and whether those systems can make outbound connections to internal services they do not need.

Experimental platforms can become production dependencies

Machine-learning tooling has often developed inside flexible research environments where data scientists need freedom to install packages, test models, and connect new services quickly. As AI moves into production, the same platforms can become shared infrastructure without necessarily receiving the authentication, segmentation, ownership, and monitoring expected of a conventional production application.

That transition creates a security gap unrelated to model behaviour. Organisations may invest heavily in prompt filtering, model governance, and agent permissions while the experiment tracker, model registry, notebook environment, vector database, or deployment service around the model still carries ordinary software vulnerabilities.

The more integrated the AI stack becomes, the more those components matter. A model-management platform can sit near expensive computing resources, commercially sensitive data, cloud credentials, and systems used to promote software from development into production, raising the consequences if a weakness allows an attacker to cross network boundaries.

Security teams therefore need AI asset inventories that extend beyond the models themselves. Knowing which model an organisation uses is less useful during vulnerability management than knowing which versions of MLflow, orchestration tools, gateways, databases, and runtime components are installed and who is responsible for maintaining them.

The issue also argues for treating internet exposure as an explicit architectural decision rather than a default convenience. Development tools frequently provide web interfaces intended to make collaboration easier, but opening those systems broadly can convert a vulnerability that requires internal access into one reachable from outside the organisation.

CVE-2026-64849 is not an exotic failure caused by artificial intelligence; it is a familiar application-security weakness appearing inside software built specifically for AI engineering. That distinction is useful because it shows how much of AI resilience still depends on mature operational practices rather than model-specific safeguards.

As machine learning becomes ordinary production infrastructure, its supporting software will attract the same scrutiny and exploitation as any other widely deployed enterprise stack. MLflow users now have a fixed release available and evidence that the flaw is being used, leaving version discovery, patching, network restriction, and monitoring as the immediate work rather than waiting for another AI-specific security framework to solve a conventional problem.