CISA KEV: Browser-Based RCE Now Targets Ray ML Developer Machines

CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog on 17 August 2026, with a remediation deadline of 20 August for federal agencies under BOD 26-04. The three-day window is short. It signals confirmed active exploitation, not theoretical risk. And the attack surface is different from everything that came before in the Ray story.

Previous Ray attacks went after servers: internet-exposed clusters running with open dashboards, compromised through direct API access and turned into cryptomining nodes and credential harvesters. The ShadowRay 2.0 campaign, covered on this site in August, put the number of exposed internet-facing Ray servers at over 200,000. The fix was straightforward in principle: don’t expose the Ray Dashboard to the internet. Lots of teams never did.

CVE-2025-62593 changes the equation. This attack doesn’t need an internet-exposed cluster. It needs a developer with Ray running locally and Firefox or Safari open.

How the Attack Chain Works

Ray’s Dashboard and Job Submission API, by design, accept unauthenticated job submissions. Submitting a job means executing arbitrary Python code on the Ray cluster. This is intentional behaviour in a trusted environment. The problem is that the API also, in its unpatched state, lacks the cross-site request forgery protections that would prevent a different website from triggering that submission.

The CSRF component exploits a browser-level gap. Chrome has implemented the Private Network Access specification, which blocks requests from public-web pages to private addresses (localhost, 192.168.x.x, and similar). Firefox and Safari have not. A page served from the public internet can instruct Firefox or Safari to POST a job specification to http://127.0.0.1:8265/api/jobs/ and the browser will execute that request.

The attack chain is clean. Developer starts Ray locally for a training run or experimentation. Developer opens Firefox or Safari and visits a malicious site (a phishing link, a drive-by through a compromised ad, a poisoned search result). The page’s JavaScript fires a cross-origin POST to the Ray Dashboard. Ray accepts the job, spawns a worker, runs the attacker-controlled Python. The developer doesn’t click anything. They just loaded a webpage.

What the attacker gets: code execution on the developer’s machine or cluster, with the privileges of the Ray worker process. ML development environments are rich targets. They typically contain cloud provider credentials (AWS, GCP, Azure), API keys for model providers, Hugging Face tokens, database credentials, and proprietary training data and model weights.

Why This Matters More Than Port 8265

The original ShadowRay problem was a configuration issue. Teams who understood the risk could mitigate it by firewalling port 8265. The population of internet-exposed Ray clusters, while large, is bounded to teams who made a specific infrastructure decision.

CVE-2025-62593 reaches a much larger population. Every ML developer running Ray locally, across all the research labs, startups, enterprise AI teams, and academic groups that use it for distributed experiments, is in scope. You don’t have to have done anything wrong from an infrastructure perspective. You just have to be running Ray and opening a browser.

The browser-as-attack-surface angle isn’t specific to Ray. It’s a pattern that will likely recur as more developer tooling runs local API servers without authentication, and as browser vendors move at different speeds on private network access protections. The web origin model assumes that what’s on your machine is trusted and that public web pages can’t reach it. Chrome is enforcing that assumption. Firefox and Safari are lagging.

The Broader Ray Security Picture

The timing matters. CVE-2025-62593 arrives three months after ShadowRay 2.0, which itself arrived three years after CVE-2023-48022 was first documented. The Ray project’s decision to ship an unauthenticated API by default has produced a sequence of exploitable vulnerabilities at each layer of the deployment stack: internet-exposed clusters, network-adjacent hosts, and now developer-local instances reachable only through the browser.

Oligo Security’s Black Hat 2026 presentation framed Ray as a systemic ML infrastructure security problem. This KEV addition reinforces that framing. CISA’s addition doesn’t restrict to internet-facing clusters. It addresses the product.

The upstream fix adds CSRF protections to the relevant endpoints. Ray’s authentication features, available in more recent versions, should also be evaluated for teams running production Ray deployments. Authentication shouldn’t be opt-in for a framework executing arbitrary code.

References

• The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE
• CISA — CISA Adds One Known Exploited Vulnerability to Catalog (CVE-2025-62593)