mlflow-assistant-ajax-api-rce

MLflow Assistant /ajax-api flaw lets a malicious webpage hand Claude Code sub-agent the keys, critical remote code risk for data science teams

What happened

Here’s the sticky bit up front, because you’ll want to Google it: MLflow version 3.9.0 introduced an MLflow Assistant feature whose /ajax-api endpoints fail to validate origin properly, allowing a malicious webpage to talk to the Assistant running on a victim’s machine and, crucially, enable full access to the service.

Following that change, an attacker who lures a user to a hostile page can bypass the loopback-only restriction and modify the Assistant’s configuration, which in turn allows execution of arbitrary commands via the Claude Code sub-agent. That behaviour is described in the advisory and is fixed in MLflow 3.10.0. The issue requires user interaction (a visit to a malicious page) and affects MLflow Assistant in 3.9.0.

Why this matters to businesses

Data scientists run MLflow locally and on developer machines, often with access to model artifacts, datasets, credentials and CI credentials. If an attacker can run commands through the Claude Code sub-agent, those local machines become a pivot point into build servers, dataset stores and credential vaults.

Given the severity reported (9.6, Critical), regulators, customers and partners will care fast, and affected teams will need time and people to investigate. Despite that, many orgs treat developer tooling as low priority and patch later, which is exactly the habit that turns this into a post-breach scramble.

If you’ve got the same weakness, here’s what happens next

If you leave MLflow Assistant exposed and unpatched, expect a short chain of trouble. A crafted webpage gets a click, the Assistant’s config is changed, Claude Code runs commands, secrets or tokens leak, and attackers use them to access other systems quietly.

Although this isn’t a Hollywood ransomware blast, it can still mean stolen model IP, exfiltrated training data, CI/CD pipeline compromise or lateral movement into production. Recovery eats time, contracts get delayed and security teams spend days on containment rather than improvement.

What to do on Monday morning

1. Patch first: upgrade MLflow to 3.10.0 where the issue is fixed, or disable the MLflow Assistant until you can confirm a safe version.

2. Harden local tooling: restrict access to MLflow endpoints to localhost-only by OS firewall or browser policy and block unexpected cross-origin requests to developer machines.

3. Rotate and audit credentials: rotate any API keys or tokens that might be accessible from developer machines and check CI credentials for unexpected use.

4. Hunt in logs: look for unusual /ajax-api requests, configuration changes of the Assistant and suspicious CLI executions on data science hosts.

5. Contain and isolate: isolate affected developer machines from build and dataset storage until you’ve confirmed integrity, and snapshot systems for forensic review.

6. Fix the human vector: remind teams not to open unknown links from strangers, and run a quick simulated phish or awareness message for data teams.

7. Update supplier and third-party controls: if MLflow is used by partners or consultants, confirm they’ve patched and that service agreements require patching of developer tooling.

8. Test recovery: verify backups and model artifact integrity so you can restore clean environments quickly if needed.

Where ISO standards fit, without the sales pitch

An ISO-aligned approach would have cut the blast radius here by treating developer tooling and local services as part of the attack surface rather than optional extras.

Following an ISO 27001-aligned risk process, you’d identify MLflow Assistant as a risk, require version control and patching, and enforce access controls across environments, see how that maps in practice at Synergos’ ISO27001 guidance.

When continuity and recovery matter, for example if model training pipelines feed production, a business continuity plan tested against developer-tooling loss helps, see Synergos on ISO 22301.

Baseline controls such as inventory, patch management and secure configuration are straightforward, and if you want certification-style baseline checks see IASME material.

Since this attack needs a malicious webpage and user interaction, human behaviour training and simulated phishing matter, see practical options at usecure.

In short, the fix is not just a patch, it’s a short programme of configuration, access control and user awareness so you don’t get caught again.

Think about MLflow, Claude Code and the /ajax-api endpoints this week, not next quarter.