If you run Ray clusters for distributed machine learning workloads, your developers might be one malicious browser tab away from handing an attacker a shell on your infrastructure. CISA added CVE-2025-62593, a critical code injection vulnerability in the open-source Ray framework, to its Known Exploited Vulnerabilities catalog on August 17, 2026, confirming the flaw is under active exploitation in the wild.
The vulnerability carries a CVSS score of 9.4 and allows unauthenticated remote code execution through ordinary web browsers, specifically Mozilla Firefox and Apple Safari. The fix is simple: update to Ray version 2.52.0 or higher. The deadline is not: federal agencies have until August 20, 2026, one of the tightest patch windows CISA issues, to comply or stop running the software.
For builders and operators running Ray clusters, this CVE is a reminder that AI infrastructure built for speed and scale often ships without the security primitives that production teams take for granted in traditional software stacks. Ray, maintained by Anyscale, has over 43,500 GitHub stars and more than 7,900 forks, making it one of the most widely used frameworks in modern ML pipelines. Its core job is distributing Python workloads across clusters of CPUs and GPUs, the exact kind of system data science teams spin up fast and security teams lose track of.
What does CVE-2025-62593 actually exploit?
The vulnerability sits at the intersection of two design decisions in Ray: the absence of authentication on critical API endpoints and an insufficient defense against browser-based attacks.
Ray maintains several API endpoints, including /api/jobs and /api/job_agent/jobs/, that have never required authentication. The framework's security model assumed these endpoints would only be reachable on trusted networks. The current defense mechanism against browser-based attacks relies on checking whether the User-Agent header starts with the string "Mozilla". The assumption was that this header cannot be manipulated by web browsers.
That assumption is wrong. According to the GitHub Security Advisory, the fetch API specification in Firefox and Safari allows the User-Agent header to be set to arbitrary values. An attacker can combine this with a DNS rebinding attack, a technique that has been understood for nearly two decades, to bypass the User-Agent check entirely.
The attack chain works like this. A developer running Ray locally or on a private network visits a malicious website or is served a malicious advertisement through Firefox or Safari. The attacker's page executes JavaScript that performs a DNS rebinding attack against the browser, tricking it into sending authenticated requests to the local Ray instance. Because the User-Agent header can be modified in these browsers, the attacker bypasses the Mozilla check and reaches the unauthenticated /api/jobs endpoint, achieving remote code execution on the developer's machine.
The maintainers noted that Chrome is not vulnerable to this specific fetch bypass, ironically because of a bug that brings it out of spec with the fetch specification. The attack can also be extended beyond the local machine. A developer's compromised browser can act as a confused deputy intermediary to attack Ray instances running inside a private corporate network, reaching clusters the attacker could never touch directly from the internet.
How did we get here and is it being exploited now?
The vulnerability was publicly disclosed on November 26, 2025, but exploitation started before the world knew about it. A BitSight report from March 2026 revealed that the RondoDox DDoS botnet had incorporated the vulnerability into its arsenal two days before public disclosure, on November 24, 2025, because a proof-of-concept exploit was already circulating.
Ray clusters have been a target before. Researchers at Oligo Security documented a campaign they called ShadowRay, tied to a separate and older Ray weakness, in which more than 230,000 internet-exposed servers were scanned and compromised systems were mined for cryptocurrency, credentials, and whole repositories of source code and models. The fact that this is a recurring pattern, not a one-off incident, should change how you think about the blast radius of an unpatched Ray instance.
CISA lists the vulnerability's known use in ransomware campaigns as "unknown," so there is no confirmed extortion angle at this stage. The immediate risk is unauthenticated remote code execution and everything that follows from it: credential theft, lateral movement, model exfiltration, cryptomining, and persistence.
Why does this matter for AI infrastructure operators?
This CVE exposes a structural problem in how AI infrastructure gets built and deployed. Ray is designed for performance and developer velocity. It was never designed with zero-trust or internet-exposure assumptions baked in. Data science teams install it with pip install ray, run ray start --head, and start distributing workloads across their GPU cluster. Security is an afterthought, if it is a thought at all.
The unauthenticated API endpoints are not a bug. They are a design decision. The Ray development team made a "longstanding decision" not to implement authentication on critical endpoints, according to the project's own advisory. That decision has now led to at least two severe vulnerabilities, the ShadowRay campaign and CVE-2025-62593, and it is the same root cause both times.
For operators, this has three concrete consequences:
- Your Ray clusters are probably less isolated than you think. If a developer can run
ray start --headon their laptop and connect to a production cluster, a malicious web page can reach that same production cluster through their browser. Network segmentation that does not account for browser-as-confused-deputy attacks is incomplete. - Your developers are the attack surface. Traditional network security assumes the threat comes from outside. This CVE proves that a developer visiting the wrong website in Firefox or Safari can become the entry point for an attack on your internal infrastructure. Phishing and malvertising are now infrastructure attack vectors.
- Your AI assets are the target. The ShadowRay campaign showed that attackers will mine compromised clusters for credentials, source code, and trained models. If your Ray deployment has access to GPU resources, proprietary model weights, or training data, it is a high-value target, and the lack of authentication makes it a low-effort one.
If you are running an AI agent prototype that touches Ray, the risk profile is even worse. An agent with code execution capabilities that can interact with Ray APIs could be tricked into running arbitrary commands on your cluster, similar to the AutoJack agent RCE risk we covered previously.
What should I do about it right now?
The immediate action is straightforward. Update to Ray version 2.52.0 or higher. The update also adds a disabled-by-default authentication feature that can further harden your deployment, documented in the Ray token authentication guide. Enable it.
Beyond the patch, take these steps:
- Find every Ray instance on your network. Run a network scan or query your asset inventory for any host running the Ray dashboard or API on ports 8265, 10001, or any custom port your teams configured. Do not assume your data science team told you about every deployment.
- Restrict network access to Ray API endpoints. If Ray does not need to be reachable from the internet, make sure it is not. If it does, put it behind a VPN, a bastion host, or a reverse proxy with authentication. The unauthenticated
/api/jobsendpoint should never be exposed to the public internet. - Audit browser security policies for developers running Ray locally. Consider restricting access to untrusted websites in Firefox and Safari for developers who run Ray locally, or enforce Chrome for general browsing until DNS rebinding protections in Firefox and Safari mature.
- Inventory GPU resources and model access paths. If an attacker compromises a Ray cluster, they gain access to everything that cluster can reach: credentials, model weights, training data, and GPU compute. Map those access paths now, before you need to.
If you cannot patch immediately, CISA's guidance under Binding Operational Directive 26-04 is clear: discontinue use of the product if mitigations are unavailable. For Ray, mitigations are available, but if you cannot apply them in the 72-hour window, take the clusters offline until you can.
The deeper problem with AI infrastructure security
Ray's unauthenticated API endpoints are a symptom of a broader pattern in AI tooling. Frameworks built for research and experimentation are being deployed into production environments with the same security posture they had in a lab. MLflow, Langflow, and now Ray have all shipped critical RCE vulnerabilities in the past year that stem from the same root cause: the assumption that the network is trusted.
We previously covered how Langflow RCE turns AI app endpoints into miner bait and how MLflow SSRF flaws let attackers steal cloud credentials. Ray joins a growing list of AI infrastructure components that were built for speed, not for security, and are now being deployed at a scale where the lack of security primitives creates systemic risk.
The pattern is clear. AI infrastructure frameworks treat authentication as optional, network exposure as controlled, and developers as trusted actors. Attackers exploit all three assumptions. The ShadowRay campaign compromised over 230,000 servers. RondoDox added Ray to its botnet arsenal before the vulnerability was even publicly disclosed. CISA has now confirmed active exploitation of a second Ray weakness.
For builders, the takeaway is that the security debt in AI infrastructure is coming due. The frameworks you use to train and serve models were not built with the security primitives your production environment requires. You need to add them yourself, or you need to accept that every unauthenticated API endpoint on your AI infrastructure is an open door for anyone who can reach it, whether through the internet or through a developer's browser.
Sources
- cisa.gov - Known Exploited Vulnerabilities Catalog
- github.com - Ray Security Advisory GHSA-q279-jhrf-cc6v
- thehackernews.com - CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE
- thenextweb.com - CISA orders a three-day patch after a flaw in the Ray AI framework comes under active attack
- realhacker.news - CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE
