Windows ML CLI RCE: Can Any Website Run Code?

September 10, 2026

Microsoft says a malicious webpage could turn Windows ML CLI's localhost API into code execution. See who is affected and why 0.4.0 matters.

Yes—Microsoft's security record says a malicious website could send requests to a vulnerable Windows ML CLI server on your own computer and trigger arbitrary code execution. CVE-2026-84452 combines an unauthenticated localhost API, wildcard cross-origin access, and a remote-code-loading option. The flaw affects winml-cli versions before 0.4.0.

The surprising part is the route: an attacker did not need to expose the local server directly to the internet. The victim only had to run the affected server and load an attacker-controlled page in a browser. That page could reach the loopback service because the service allowed requests from any web origin.

There is also a release-availability problem operators should not overlook. The advisory identifies version 0.4.0 as the fix, but at this article's September 10 research cutoff, the public PyPI project and Microsoft's repository metadata still identified 0.3.1 as the current package version. A security fix exists in Microsoft's source repository, but operators should verify that the exact artifact they install actually contains it.

Research cutoff: September 10, 2026. This article separates the reviewed vulnerability record, Microsoft's source-code fix, current package availability, and the impact questions that remain unanswered.

What Is Confirmed

The GitHub reviewed advisory for CVE-2026-84452 describes a high-severity remote-code-execution flaw in Microsoft's Windows ML CLI. The affected package is winml-cli for Python, and the listed affected range is every version before 0.4.0.

The CVE record gives the issue a CVSS 4.0 score of 8.6. Its vector describes a network-reachable attack with low complexity, no required privileges, active user interaction, and high impact to confidentiality, integrity, and availability.

The confirmed chain has three linked weaknesses:

• Windows ML CLI's server exposed command-line operations through an HTTP API without authentication;
• the server accepted cross-origin browser requests by using a wildcard CORS policy; and
• its build and configuration paths accepted trust_remote_code, allowing Python from an attacker-selected model repository to be imported.

According to the advisory, the vulnerable server listened on localhost by default. That reduced direct network exposure, but it did not isolate the service from the browser running on the same machine. A malicious page could send a cross-origin request to the local API, select a hostile model repository, enable remote-code loading, and cause that repository's Python code to run with the server process's user privileges.

Microsoft merged a security hardening pull request on August 21. The associated source commit says it:

• replaced wildcard CORS with same-origin request protection;
• rejected HTTP attempts to enable remote code;
• enforced the policy again at model and configuration loading boundaries;
• centralized the set of CLI commands the server may invoke; and
• added tests for origin parsing, DNS rebinding, malformed headers, nested configuration, and direct CLI compatibility.

That is a defense-in-depth fix. It does not rely on only one header check or only one blocked parameter.

What Is Still Unclear

The reviewed public sources do not establish:

• exploitation against a real Windows ML CLI user;
• how many people ran the vulnerable server;
• how long any affected server was active;
• whether a malicious site attempted to probe the localhost endpoint in the wild;
• whether code, model files, tokens, prompts, or other local data were accessed;
• a complete set of forensic indicators for detecting an attempted attack; or
• whether every package channel already distributes a fixed artifact.

The version question is especially important. GitHub and the CVE record name 0.4.0 as fixed. At the research cutoff, however, the official PyPI project page exposed metadata whose latest version was 0.3.1, and Microsoft's main pyproject.toml also still declared 0.3.1. The security commit was present in the repository, but the repository did not show a corresponding 0.4.0 release in its public releases feed.

That does not mean the fix is ineffective. It means a fixed source commit and an installable fixed package are separate facts. An operator should not treat a version number in an advisory as proof that their package manager can already retrieve that version.

What Is Windows ML CLI?

Windows ML CLI is a Microsoft developer tool for preparing, validating, and deploying AI models for Windows ML. It is not the same thing as Windows itself, Copilot, or every local AI application on Windows.

The vulnerable component was the tool's serving layer. It offered an HTTP interface over selected CLI operations so another local interface could ask the tool to build, configure, inspect, or work with a model.

That distinction prevents two misleading headlines:

• the advisory does not say every Windows computer was remotely exploitable; and
• it does not say merely downloading an AI model triggered code execution.

The documented preconditions include an affected winml-cli version, the local API running, and the user visiting a malicious or compromised page. The model repository becomes part of the chain because the vulnerable API allowed the request to turn on remote-code loading.

How Can A Website Reach Localhost?

Developers often treat 127.0.0.1 or localhost as a private boundary. It is useful, but it is not an authentication mechanism.

A normal remote computer cannot directly connect to another user's loopback interface. The user's own browser can. When a page loads, JavaScript runs on the user's device and can attempt requests to network services reachable from that device, including loopback ports.

Browser same-origin rules usually limit what one website can read from another origin. CORS lets the target server relax that rule. If a localhost service responds with a wildcard policy, it can tell the browser that any website is allowed to interact with it.

This is why the phrase “localhost only” was not enough here. The attacker used the browser as the local network client.

The broader lesson also applies to model dashboards, vector databases, agent gateways, notebook servers, browser extensions, and local media tools. A service can be unreachable from the public internet and still be reachable from:

• a webpage in the user's browser;
• another process on the machine;
• a browser extension;
• a container with host networking;
• a development tunnel or editor port forward; or
• malware already running under the account.

Our guide to AI server attacks against LiteLLM and MCP explains why binding, authentication, tool authority, credentials, and outbound access must be evaluated separately.

Why Did trust_remote_code Matter?

Some Hugging Face model repositories need custom Python classes that are not built into the standard Transformers library. The trust_remote_code option tells the loader it may import and execute that repository's custom Python.

That can be legitimate when a developer has intentionally reviewed and selected a trusted repository. It becomes dangerous when an untrusted request can choose both the repository and the trust decision.

The CVE record says Windows ML CLI converted a JSON true value into the --trust-remote-code command-line flag without rejecting it on the HTTP path. The selected repository then reached AutoConfig.from_pretrained with remote code enabled. Code in the repository could run during import, before the intended model operation completed.

This is an authority problem, not a mysterious property of AI weights. A remote-code switch is equivalent to permission to run software. It should never be exposed as a freely selectable option to an unauthenticated browser request.

Does The Browser Prompt The User Before The Code Runs?

The advisory's CVSS vector requires active user interaction because the user must load an attacker-controlled page. It does not describe a second confirmation dialog inside Windows ML CLI.

That difference matters. “User interaction required” in a vulnerability score can mean visiting a webpage, opening a document, or clicking a link. It does not necessarily mean the user sees and approves the final dangerous action.

The public proof description says the payload ran when Python imported the repository's module. Even if the surrounding build command later returned an error, the code-execution step could already have occurred.

What Should Windows ML CLI Operators Do Now?

1. Confirm Whether The Package Is Present

Check the Python environments, virtual environments, developer images, notebooks, and build machines that might contain winml-cli. Do not rely only on the package list from your currently active terminal if the service may run from another environment.

python -m pip show winml-cli can identify a package in the selected Python environment. On Windows, also inspect the command line of the process that started the service so you know which interpreter and environment it uses.

2. Stop The Vulnerable Server

If an affected server is running, stop it until you have a verified fixed artifact or an equivalent reviewed backport. Closing a browser tab does not remove the vulnerable localhost API, and a firewall rule aimed only at inbound internet traffic does not correct the cross-origin design flaw.

If the service is not needed, remove it from development startup scripts, task runners, login tasks, container configurations, and editor integrations.

3. Verify The Exact Fix, Not Just The Label

The advisory's fixed boundary is 0.4.0, but that version was not visible through the public package metadata checked for this article. Before installing anything presented as fixed:

• confirm the repository and publisher;
• confirm the exact package version and file hashes;
• verify the release contains Microsoft's August 21 hardening commit or an equivalent later change;
• rebuild or redeploy the environment that actually runs the server; and
• retest the HTTP interface from an unrelated web origin.

Avoid downloading an unofficial wheel or archive merely because it uses the expected version number. A vulnerable-package story is precisely the wrong moment to lower your software-supply-chain standards.

4. Look For Exposure And Suspicious Activity

Review process, browser, endpoint, proxy, and development logs for the period when the server was active. Useful questions include:

• Was the server process listening on its expected loopback address and port?
• Did it receive build or configuration requests you cannot explain?
• Did Python create unexpected child processes, files, scheduled tasks, startup entries, or outbound connections?
• Were unfamiliar model repositories or revisions downloaded?
• Did the process have access to cloud credentials, source repositories, signing keys, browser data, or sensitive model files?

The absence of a public exploitation report is not proof that one deployment was untouched. Your own telemetry is the evidence that matters.

5. Rotate Secrets When Evidence Justifies It

If logs or endpoint evidence show an unknown repository was imported or arbitrary code may have run, treat every credential accessible to that process as potentially exposed. Rotate keys through their owning systems, revoke old sessions, review recent activity, and preserve authorized evidence before cleanup.

Do not rotate every organizational secret solely because a vulnerable package existed on one machine. Scope the response to the identity, environment, accessible files, and execution period, then expand if evidence requires it.

A Local AI Security Checklist

Use ORIGIN to review any browser-accessible local AI service:

• O — Origins: Which browser origins may call the service, and are Origin and Host validated safely?
• R — Requests: Which routes exist, and which require authentication or anti-forgery protections?
• I — Identity: Which operating-system user, cloud identity, tokens, and files can the process access?
• G — Granted actions: Can requests run commands, install packages, load custom code, write files, or open network connections?
• I — Install source: Which exact signed or hashed artifact is deployed, and does it contain the documented fix?
• N — Network: What can reach the service, and what can the service reach after a request arrives?

This checklist is more reliable than asking whether the model is “local.” Local model execution can keep inference data off a hosted model endpoint, but the surrounding application still has browsers, ports, packages, update paths, logs, and credentials.

For the broader tradeoff, see Private AI Chat vs Local AI. If you operate Ollama, the local-only verification guide shows how to test network behavior instead of assuming it from a label.

What This Means For Privacy

Remote code execution is not automatically proof of a data breach. The public record does not identify real victims or stolen information. It does show why a local deployment's privacy depends on the security of the full application stack.

Code running as the server user may be able to reach:

• downloaded models and configuration files;
• prompt or evaluation artifacts stored by the tool;
• source code and project directories;
• environment variables and developer credentials;
• accessible browser or user-profile data; and
• internal services reachable from the workstation.

The exact impact depends on operating-system permissions and local configuration. A low-privilege isolated service account has a different blast radius from a developer account with source-control, cloud, package-registry, and signing credentials.

The same separation helps when evaluating privacy claims. Ask where inference occurs, where history is retained, what active request processing happens, what software can execute, and which identities the process inherits. What To Check Before Trusting Any AI Privacy Claim provides a broader framework.

Where OpenVeil Fits—and Where It Does Not

OpenVeil is an 18+ hosted, privacy-focused AI workspace. For normal private chat sessions, history is stored in the user's browser, and OpenVeil does not maintain a conventional server-side chat-history record. OpenVeil also does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.

That can be a useful alternative for adults who want conversational AI without operating a local model server or granting an agent local shell, package-installation, repository, or broad workstation authority.

OpenVeil is not:

• a Windows ML CLI patch or vulnerability scanner;
• a localhost firewall or browser security control;
• a code sandbox, endpoint-security tool, or incident-response service;
• fully offline, anonymous, or zero-log; or
• protection for files and credentials already exposed to unrelated software.

Active OpenVeil prompts and requested features still require processing by OpenVeil and necessary providers. Browser-local normal chat history changes the routine retention boundary; it does not make hosted inference local or eliminate operational records required for accounts, billing, security, routing, and service delivery.

If your requirement is that prompts never leave hardware you control, use a properly secured local workflow and accept the maintenance responsibility. If you want hosted convenience with browser-local normal chat history, try OpenVeil after reviewing its documented boundaries.

Frequently Asked Questions

Is CVE-2026-84452 A Windows Operating-System Vulnerability?

No. The affected software is Microsoft's Python package winml-cli, specifically its HTTP serving layer. The advisory does not say every Windows installation, Windows ML runtime, or Copilot user is affected.

Can Any Website Hack Localhost?

Not automatically. A website needs a reachable local service with a vulnerable request path or unsafe browser-access policy. In this case, wildcard CORS and the unauthenticated command API removed protections that should have separated unrelated websites from privileged local operations.

Does The Attack Require The Server To Be Publicly Exposed?

No. The documented browser path works against the default localhost listener because the browser itself runs on the victim's device. Direct public exposure would create additional risk, but it is not required for this chain.

Does The User Have To Approve trust_remote_code?

The vulnerable HTTP path accepted that value from the request and converted it to a command-line flag. The public advisory does not describe an additional approval dialog before the custom Python import.

Which Versions Are Affected?

The reviewed advisory lists winml-cli versions before 0.4.0 as affected and identifies 0.4.0 as the patched version.

Is Version 0.4.0 Available On PyPI?

It was not visible in the public PyPI metadata at the September 10 research cutoff; 0.3.1 remained the latest identified release. Check the current official package page and Microsoft repository before acting, because availability can change after publication.

Is The Source Repository Fixed?

Microsoft merged a substantial hardening commit on August 21. It adds same-origin checks, blocks remote-code activation through HTTP, restricts callable commands, and adds regression tests. Operators still need an artifact containing that code.

Was This Exploited In The Wild?

No reviewed source establishes in-the-wild exploitation. That is different from proof that no vulnerable deployment received malicious requests.

Does Running A Model Locally Guarantee Privacy?

No. Local inference can keep model inputs off a hosted inference endpoint, but the surrounding application may still expose ports, execute downloaded code, retain logs, load extensions, contact update services, or inherit sensitive credentials.

Does OpenVeil Fix Windows ML CLI?

No. OpenVeil does not patch or inspect Windows ML CLI and cannot protect a workstation after arbitrary code execution. Its relevant fit is narrower: hosted conversational AI for adults who do not need to operate a local AI server or grant an agent workstation authority.

Bottom Line

CVE-2026-84452 is a confirmed high-severity localhost-to-code-execution flaw in Windows ML CLI, not a confirmed breach of every Windows AI user. A malicious website could use the victim's browser to call an unauthenticated local API, enable remote-code loading, and import Python from an attacker-controlled model repository.

Microsoft's source fix addresses the chain at multiple boundaries, but operators must verify that their installed artifact actually contains it. At the research cutoff, the advisory's fixed 0.4.0 version was not yet visible in the public PyPI metadata, so stopping the vulnerable service is safer than pretending an unavailable upgrade has already solved the problem.

The durable lesson is simple: localhost is a routing choice, not authentication; a model repository can be code, not just weights; and “local AI” is private only when the entire runtime, browser boundary, package chain, permissions, and network path are secured.