Ray CVE-2025-62593: Botnet Beat the Patch, CISA Gives Feds 3 Days

Last updated: August 23, 2026

On August 17, 2026, CISA added CVE-2025-62593 - a critical remote code execution flaw in Ray, Anyscale's open source distributed AI compute framework - to its Known Exploited Vulnerabilities catalog and gave federal civilian agencies until August 20 to patch. Three days, not the usual two weeks. The reason for the urgency is a timeline most vulnerability programs have never had to plan around: according to BitSight research published in March 2026, the RondoDox DDoS botnet added an exploit for this flaw to its toolkit on November 24, 2025 - two days before the CVE and the fix were published on November 26. Exploitation beat disclosure because a proof-of-concept was already circulating (The Hacker News).

If your team runs GPU training jobs, inference serving, or agent fleets on Ray, this is the decision-intent version of the story: are you exposed, what do you patch, and what should you change about how AI infrastructure gets operated.

What the vulnerability actually is#

CVE-2025-62593 affects every Ray version below 2.52.0 and carries a CVSS v4.0 score of 9.4 CRITICAL from GitHub (the CVE numbering authority here), with NVD scoring it 8.8 HIGH under CVSS v3.1 (NVD). It pairs two weaknesses, tagged CWE-94 (code injection) and CWE-352 (cross-site request forgery) in the CISA KEV entry:

1. Ray's only defense against browser-originated attacks on its dashboard API was checking that the HTTP User-Agent header starts with "Mozilla". As the advisory states, the fetch specification lets browsers modify that header, so the guard is trivially bypassed (GHSA-q279-jhrf-cc6v).
2. Combined with DNS rebinding, an attacker can make your browser send requests to localhost. Visit a malicious website or load a malicious ad in Firefox or Safari while Ray runs locally, and the page can silently hit the job submission endpoints (/api/jobs and /api/job_agent/jobs/) on port 8265. Those endpoints ship without authentication by design, so they execute whatever the attacker submits (securityaffairs.com).

Note who is the target: not a head node with a public IP, but a developer's laptop running ray start --head during development. Oligo researcher Avi Lumelsky originally theorized the fetch bypass, and Jonathan Leitschuh built the DNS rebinding proof of concept and coordinated disclosure (OSV PYSEC-2026-520). The fix in commit 70e7c72, released in Ray 2.52.0 on November 26, 2025, rejects browser-initiated POST and PUT requests by validating Sec-Fetch headers (THE DAILY BRIEF analysis).

The exploit-beats-disclosure chain#

The full timeline is worth internalizing because each step is a lesson:

Two campaigns give the exploitation context. RondoDox, a DDoS botnet, used the flaw as one more recruitment vector - its exploit attempts were identifiable by a spoofed Mozilla/5.0 (rondo2012@[.]io) user-agent and rondo.XXX.sh staged shell scripts (indicator reporting). Separately, Oligo documented ShadowRay 2.0, a cryptojacking campaign against exposed Ray clusters abusing the older CVE-2023-48022 issue - which Ray maintainers classed as intended behavior for trusted networks rather than something to patch. ShadowRay 2.0 operators ran XMRig miners disguised as system worker processes, capped CPU usage near 60 percent to evade monitoring, hid GPU consumption, persisted via cron and systemd, and used Ray's own scheduling APIs to spread laterally across nodes (indicators summary). Reporting tied to these campaigns counted more than 230,000 Ray servers reachable from the open internet.

The pattern across both: attackers monetize idle AI compute within days, and they watch researcher activity, not just vendor calendars.

Why AI infrastructure gets hit ahead of patch#

Three structural reasons this category keeps losing, and none of them are about the specific bug:

GPU clusters are valuable and measurable. Compromised web servers are worth cents; hijacked H100 time mines Monero-grade payouts or trains stolen models. ShadowRay 2.0 treated whole clusters as compute inventory, using the victim's own scheduler to distribute miners.

Ephemeral infra skips patch cycles. Ray clusters get stood up for a training run, torn down, and rebuilt from stale base images. Nobody's config management pins ray>=2.52.0 on an image built in October. The result is a fleet that is permanently one release behind whatever attackers are scanning for.

Developer machines are the soft edge. This CVE specifically weaponizes a laptop running Ray locally. Your cluster firewall does nothing when the exploit arrives through a browser tab. The same shift happened with agent frameworks - Langflow landed on CISA's must-patch list in July (our coverage), and malicious packages targeting AI developers keep surfacing in npm supply chain attacks (analysis). Attackers follow the workload.

Is your Ray deployment exposed?#

Run through this in order. Each step takes minutes.

Version check. ray --version or pip show ray on every image you ship. Anything below 2.52.0 is vulnerable to CVE-2025-62593 outright (Anyscale). But do not stop at the minimum: OSV shows Ray 2.53.0 is still affected by three later advisories - a WebDataset decoder RCE (GHSA-hhrp-gw25-jr43), a Parquet deserialization RCE (GHSA-mw35-8rx3-xf9r), and unauthenticated DELETE endpoints on the dashboard (GHSA-q5fh-2hc8-f6rq). Upgrade to the current release, not the floor.

Network reachability. Check whether ports 8265 (dashboard and Jobs API), 8266, 10001, and 6379 answer from outside your VPC. Cloud security groups that default-allow east-west traffic inside a shared account count as exposed. Ray's own security model assumes a trusted network - maintainers state that security and isolation must be enforced outside the cluster (Oligo) - so the network boundary is your job, not Ray's.

Authentication. Token authentication exists in recent Ray releases but ships disabled by default. Enabling it is a deliberate act; upgrading alone will not turn it on (Anyscale). Be aware that scanners will not nag you about this - the CVE filed against the insecure default was rejected, and the underlying design stance remains disputed rather than patched, so your dependency scanner sees only the version number.

Compromise triage. If any node ran a vulnerable version with external reachability before you patched, CISA's KEV entry requires forensic triage alongside remediation, not after it. Look for unauthenticated job submissions to /api/jobs/, XMRig processes wearing system names, new cron or systemd units, CPU pinned suspiciously below capacity, and jobs spreading across nodes that no human submitted (detection indicators).

Hardening Checklist#

• Pin ray to the current stable release in every Dockerfile and environment lockfile; fail CI builds on versions below it
• Bind the dashboard and Jobs API to loopback or a private subnet; never publish 8265 through a load balancer
• Lock down security groups: deny inbound 8265/8266/10001/6379 from anything outside the cluster subnet
• Enable token authentication explicitly after upgrade; verify a request without a token gets rejected
• Restrict egress from worker and head nodes to known registries and storage endpoints - a miner needs outbound channels to phone home
• Alert on new jobs whose submitter has no human owner, on /api/jobs/ calls arriving from non-cluster IPs, and on process names like kworker appearing off-pattern
• Rebuild ephemeral clusters from freshly patched images rather than long-lived snapshots
• Add AI frameworks (Ray, Langflow, ComfyUI, anything with a dashboard) to your vulnerability program as first-class assets with their own SLA, not as dev tools
• Treat any KEV listing for AI infrastructure as a same-week incident, matching the federal clock even if you are not bound by it

That last bullet is the fleet-level lesson. The old assumption was that a vulnerability becomes dangerous at disclosure. CVE-2025-62593 became dangerous two days before disclosure, got a three-day federal clock eight months later, and the whole window compressed around infrastructure teams treat as disposable. Skills and config files are executable surface too, which is why we treat agent configuration as part of the supply chain - same logic applies to the frameworks underneath your agents.

FAQ#

Am I affected by CVE-2025-62593?#

If you run Ray below 2.52.0, yes, in its development-machine attack path. Verify with ray --version or pip show ray, then upgrade. Versions 2.52.0 and later contain the fix for the browser-based attack (Anyscale).

Does upgrading to 2.52.0 fully protect my cluster?#

It closes the KEV item but not the category. Later advisories - including two RCE-class flaws in Ray Data decoders fixed in 2.54.0 through 2.56.0 - remain open on older builds (OSV data), and token authentication still ships disabled. Go to the current release and turn auth on.

What did the botnets actually do with exploited clusters?#

RondoDox recruited vulnerable Ray instances into a DDoS botnet. ShadowRay 2.0 installed disguised XMRig miners, hid GPU consumption, persisted with cron and systemd, and spread laterally using Ray's own job scheduling APIs (reported indicators).

Why does the attack only work in Firefox and Safari?#

Those browsers permit the DNS rebinding and header manipulation sequence the exploit needs. The advisory scopes the practical exploit to them, though treating that as permanent safety margin would be a mistake - browser boundaries move (GHSA-q279-jhrf-cc6v).

Why did CISA give agencies only three days?#

BOD 26-04 replaced the flat two-week KEV deadline with a risk-based model. Unauthenticated RCE yielding total control of an automatable, internet-reachable asset lands in the top tier: three days plus mandatory forensic triage (directive text).

My Ray cluster has no public IP. Should I still care?#

Yes. This flaw reaches machines through a developer's browser, so the laptop running ray start --head at a coffee shop is the entry point. Network isolation protects clusters; it does not protect the humans operating them.

Does the CISA deadline apply to private companies?#

No, it binds US federal civilian agencies. For everyone else it is a signal: when the government compresses remediation to 72 hours, exploitation is confirmed and automated. Non-federal teams have no legal deadline, which is exactly why the discipline has to be self-imposed.

How do I check whether I was already compromised?#

Pull job submission history from the dashboard API for entries you cannot attribute, compare running processes against expected workers, audit cron and systemd units on every node, and review egress logs from the cluster subnet for connections to mining pools or unknown hosts (triage indicators).

Where this fits#

AI infrastructure is now a first-class attack surface with government-grade urgency attached, and the pressure keeps moving up the stack: build-time malware in Rust packages (rust-arrayref-build-time-malware-2026), info-stealers distributed through AI developer tooling (miasma-supply-chain-attack-ai-developers), and prompt-injection-driven compromise paths in coding agents (hallusquatting-ai-coding-agent-security). If you operate agent fleets on top of frameworks like Ray, our comparison of how major agent platforms model security covers the layer above. Patch the floor, harden past it, and assume the next exploit lands before its CVE does.