CRITICAL: Ray CVE-2025-62593 Added to CISA KEV After Active Exploitation

Nothing says your infrastructure has truly arrived like a spot on CISA's Known Exploited Vulnerabilities catalog. Ray, the open source distributed computing framework that quietly underpins an enormous share of the world's machine learning training and inference pipelines, earned that honor on August 17, 2026, when CISA added CVE-2025-62593 to the catalog and gave federal civilian agencies until August 20 to remediate. Three days. That is not the deadline an agency hands out when it feels relaxed about something.

The vulnerability carries a CVSS v4.0 score of 9.4, critical by any reading, with a v3.1 score of 8.8 for organizations still scoring on the older scale. It affects every version of Ray prior to 2.52.0, and the fix has been available since late November 2025. What makes this one worth your Tuesday morning is not the age of the patch but the shape of the attack, because this is a remote code execution bug that fires when a developer does nothing more dangerous than open a web page.

The Bug Is a Browser Problem Wearing an Infrastructure Costume

Ray exposes a dashboard and a job submission API, typically on port 8265, and those endpoints ship without authentication by default. That design choice has always been defended with the same argument, namely that Ray is meant to run on a trusted internal network and the operator is responsible for keeping it off the internet. Fair enough in theory. The problem is that "internal network" includes the loopback interface on a machine learning engineer's laptop, and a browser running on that laptop is very much on the inside.

The Ray maintainers knew browsers were a threat, which is why the code included a defense. Requests hitting the sensitive endpoints, notably /api/jobs and /api/job_agent/jobs/, were checked to see whether the User-Agent header started with the string "Mozilla". If it did, the request was assumed to be an unwitting browser and got rejected. The logic was reasonable right up until somebody read the fetch specification closely and noticed that the User-Agent header is not on the forbidden header list in every implementation. Firefox and Safari both allow a script to set it to whatever it likes. Chrome happens to be unaffected, not because Google designed it that way on purpose but because a bug in Chrome's implementation prevents the header from being modified. Accidental security is still security, though it is a thin thing to build a program on.

With the User-Agent check neutralized, the rest of the chain is textbook. An attacker stands up a malicious page, using something like NCC Group's Singularity framework, and a visiting browser gets served DNS records with a very short time to live. The initial lookup points at attacker infrastructure so the page loads and the JavaScript runs. A moment later the same hostname re-resolves to 127.0.0.1, and now the attacker's script is talking to the developer's local Ray dashboard while the browser cheerfully believes it is still on the same origin. The script submits a job, and Ray does what Ray does, which is run the code it was given. Arbitrary shell commands, executing with the privileges of whoever launched the cluster.

That is why the CVSS vector carries user interaction as a requirement and still lands at 9.4. The interaction in question is browsing. NVD tags the issue under CWE-94 for code injection and CWE-352 for cross site request forgery, and the scope metrics are set to high across confidentiality, integrity and availability for both the vulnerable component and everything downstream of it. That downstream part matters more than the headline number, because a Ray cluster is rarely just compute. It holds cloud credentials, object storage keys, model weights, training datasets and whatever API tokens the data science team wired into their pipeline six months ago and never rotated.

Exploitation Is Not Theoretical and It Started Early

Here is the detail that should reframe how you think about the timeline. BitSight published research in March 2026 showing that the operators behind the RondoDox DDoS botnet had already integrated this vulnerability into their toolkit two days before it was publicly disclosed on November 26, 2025. Not two days after. Two days before. Somebody was watching the commit history, or the advisory drafting process, or had found the same bug independently and was waiting. Either way, the window between disclosure and weaponization was negative, and every organization that treated the November advisory as a routine dependency bump was already behind.

RondoDox is not the only party interested. Ray clusters have been under sustained assault through the campaign Oligo Security tracks as ShadowRay 2.0, which hunts exposed Ray dashboards and job submission APIs and converts the clusters behind them into a self replicating cryptomining and DDoS botnet. The attraction is obvious once you say it out loud. These are machines packed with NVIDIA GPUs, provisioned with generous cloud budgets, frequently running unattended for days at a stretch, and monitored by teams who expect utilization to be pegged at one hundred percent because that is what training looks like. XMRig hiding inside that noise is close to invisible. Oligo's research documented well over two hundred thousand Ray servers reachable from the public internet, a staggering jump from the few thousand seen during the original ShadowRay work that ran from late 2023 into 2024. Much of that campaign leaned on CVE-2023-48022, the older missing authentication issue that Anyscale has long characterized as an intentional design decision rather than a vulnerability. Reasonable people can argue about that classification. Attackers have stopped arguing and started mining.

CVE-2025-62593 makes the situation meaningfully worse because it removes the one comfort operators had. You no longer need an internet exposed dashboard to be a target. A cluster bound tightly to localhost on a developer workstation, invisible to Shodan, firewalled from everything, is reachable through that developer's browser tab. A malicious advertisement served through a legitimate ad network is enough. The Ray maintainers said as much in their own advisory, noting that the vulnerability is exploitable against a developer running Ray who inadvertently visits a malicious website or is served a malicious ad.

What To Do Before Thursday

Upgrade to Ray 2.52.0 or later. That is the whole fix, it has been available for nearly nine months, and there is no clever mitigation that beats it. Credit for the discovery goes to Jonathan Leitschuh of Socket for the DNS rebinding methodology and Avi Lumelsky of Oligo Security for the fetch based bypass, and the patch landed in commit 70e7c72.

While you are in there, turn on authentication. Version 2.52.0 introduced an optional authentication feature for the dashboard and job APIs, and like most optional security features it is disabled by default. Enable it. The upgrade alone closes this specific bypass, but an authenticated dashboard closes the entire category of attacks that depend on Ray trusting whoever can reach the socket.

Then go find the clusters you do not know about. This is the part that takes real work. Ray gets installed with pip, it runs on laptops, it lands in CI runners, it shows up inside KubeRay deployments that a platform team stood up for one experiment and never decommissioned. Search your endpoint inventory for the ray Python package, scan internal ranges for port 8265 and the job agent port, and check your cloud accounts for GPU instances nobody has claimed. Anything listening on a non loopback interface should be bound back to localhost and fronted by an authenticating reverse proxy or reached only over a VPN.

For detection, Host header validation is your friend, because DNS rebinding attacks arrive with a Host header that does not match any hostname your dashboard should legitimately answer to. Log job submissions to /api/jobs and /api/job_agent/jobs/ and alert on any submission whose source is a browser rather than the Ray CLI or your orchestration tooling. Watch for outbound connections from GPU nodes to known mining pool infrastructure and to newly registered domains, because both ShadowRay and RondoDox need to phone home. Egress filtering on training infrastructure is unglamorous and enormously effective, since a cluster that can only talk to your object storage and your model registry is a cluster that cannot join a botnet. Finally, treat any unexplained GPU utilization pattern as worth a look, particularly overnight and on weekends when training jobs are not scheduled.

If you find evidence of compromise, assume credential theft. Rotate every cloud key, service account token and API credential that cluster could reach, and check your object storage access logs for bulk reads of training data and model artifacts. The cryptomining is the noisy part. The quiet part is whatever left with the miners.

The MSP Angle

Every client with a data science team has Ray or something like it running somewhere IT never approved, which makes an AI infrastructure discovery and hardening assessment one of the easiest engagements to sell right now. Pitch it as shadow AI inventory, deliver a list of unmanaged GPU spend and exposed ML endpoints, and the network segmentation and managed patching work that follows tends to sell itself. There is also a recurring services angle here, because the ML dependency stack moves far faster than traditional enterprise software and most clients have no patch cadence for it at all.