CVE-2025-62593 (CVSS 9.4): Ray AI Framework’s DNS Rebinding Flaw Turns GPU Clusters Into Crypto Mining Botnets — CISA Deadline Is Today

If your organisation runs AI or machine-learning workloads — even on a single developer’s laptop — today’s CISA deadline is aimed squarely at you. CVE-2025-62593, a CVSS 9.4 remote-code-execution flaw in the Ray distributed computing framework, has been on CISA’s Known Exploited Vulnerabilities (KEV) catalog since August 17, 2026. Federal Civilian Executive Branch (FCEB) agencies face a remediation deadline of August 20, 2026 — today. Meanwhile, threat actors have been quietly weaponising the flaw since at least November 24, 2025, turning unpatched Ray clusters with NVIDIA GPUs into self-replicating cryptocurrency-mining botnets under a campaign dubbed ShadowRay 2.0.

Why Ray Matters Beyond the Research Lab

Ray is not a niche academic tool. Developed by Anyscale and widely adopted across the AI/ML ecosystem, Ray powers distributed training, model inference, hyperparameter tuning, and reinforcement learning workloads at companies ranging from ambitious Indian AI start-ups to Fortune 500 data-science teams. It runs on developer laptops, Kubernetes clusters, AWS SageMaker environments, on-premises GPU racks, and managed cloud services. Because Ray is often treated as a developer dependency rather than a production server, it frequently falls outside normal vulnerability-management and patching cycles — a dangerous blind spot that ShadowRay 2.0 is actively exploiting.

India’s AI infrastructure build-out makes this particularly relevant. As domestic enterprise AI adoption accelerates — driven by initiatives in manufacturing, BFSI, healthcare, and government — Ray-powered workloads are proliferating across data centres in Pune, Bengaluru, Hyderabad, and Noida. An unpatched Ray instance on a GPU node is not just a liability for that node; as ShadowRay 2.0 demonstrates, it is a potential beachhead into the entire cluster.

Technical Breakdown: How CVE-2025-62593 Works

The vulnerability lives in Ray’s HTTP API endpoints — specifically /api/jobs and /api/job_agent/jobs/. These endpoints allow callers to submit arbitrary code that Ray will execute as cluster jobs. Ray attempted to prevent browser-based abuse by rejecting requests whose User-Agent header did not begin with “Mozilla”, reasoning that browsers would send such headers and therefore be blocked.

This defence fails on two levels:

1. Client-controlled headers: The User-Agent header is a client-supplied string. Any HTTP client — including attacker-controlled JavaScript fetching from a malicious page — can set it to any value, including strings starting with “Mozilla”.
2. DNS rebinding: An attacker hosts a domain (e.g., attack.example) that initially resolves to the attacker’s own server. A victim developer who visits the attacker’s webpage triggers JavaScript that makes a fetch request. The attacker’s DNS record is then updated to resolve to 127.0.0.1 (or the Ray cluster’s internal IP). Because the browser has already established the origin context against the attacker’s domain, same-origin policy no longer protects the local Ray API. The subsequent fetch call lands inside the Ray API, carrying attacker-supplied job code — and Ray executes it.

The result: a developer who views a malicious advertisement or visits a compromised website while Ray is running locally has arbitrary code executed on their machine — or, more dangerously, on the GPU cluster they have network access to. No credentials, no vulnerability in a browser CVE, no user interaction beyond passive page viewing.

Attribute	Detail
CVE ID	CVE-2025-62593
CVSS Score	9.4 (Critical)
Attack Vector	Network (DNS rebinding via browser)
Affected Versions	All Ray releases before 2.52.0
Fixed Version	Ray 2.52.0+
CISA KEV Added	August 17, 2026
FCEB Patch Deadline	August 20, 2026 (today)
Directive	CISA BOD 26-04

ShadowRay 2.0 and RondoDox: The Active Threat Actors

The exploitation story for CVE-2025-62593 is more alarming than the vulnerability alone. According to a BitSight report published in March 2026, the threat actors behind the RondoDox DDoS botnet incorporated this flaw into their arsenal on November 24, 2025 — two full days before the vulnerability was publicly disclosed on November 26, 2025. This is textbook zero-day weaponisation: an actor with prior knowledge of an undisclosed vulnerability operationalised it before defenders had any opportunity to patch.

The second major threat cluster is ShadowRay 2.0, a multi-purpose campaign documented by Oligo Security and Dark Reading. Once a Ray cluster is compromised, ShadowRay 2.0 deploys payloads that:

• Mine cryptocurrency using XMRig — NVIDIA GPU compute is repurposed for Monero mining at the victim’s electricity cost.
• Self-replicate by scanning for and submitting malicious jobs to other exposed Ray dashboards on the public internet, worm-style.
• Steal sensitive AI workload data — model weights, training datasets, proprietary pipelines, and API keys stored in environment variables of Ray jobs.
• Launch DDoS attacks against third-party targets, enrolling compromised GPU nodes into the RondoDox botnet.

This is not a one-dimensional cryptomining nuisance. ShadowRay 2.0 turns your AI infrastructure into a multi-capability offensive platform — simultaneously draining your cloud budget, leaking your intellectual property, and attacking others in your name.

The Zero-Trust Angle: AI Infrastructure Is Not Exempt

CVE-2025-62593 is a vivid illustration of what happens when zero-trust principles are not applied to AI/ML infrastructure. Ray was designed with an implicit trust assumption: “run it on an isolated network, and only trusted code will reach its API.” That assumption is catastrophically misapplied in the real world, where Ray instances are routinely reachable from developer laptops on corporate Wi-Fi, exposed on cloud security-group misconfigurations, or accessible via internal network paths that an initial-access foothold can reach.

A zero-trust architecture treats every service — including internal AI compute frameworks — as untrusted by default. Ray’s dashboard and job-submission API should never be network-reachable without authentication. Compare this to how we approach enterprise supply chain security: the LiteLLM supply chain attack earlier this year showed that AI middleware sitting without proper access controls becomes a highway into CI/CD pipelines and production environments. The pattern repeats: AI tools deployed without security hardening create exploitable gaps that adversaries — whether financially motivated (ShadowRay 2.0) or state-sponsored — are quick to find.

The broader lesson is also visible in how VPN and network infrastructure flaws compound risk: when a FortiGate or Cisco ASA is unpatched, it gives attackers an entry point. Once inside, an unpatched Ray instance on an internal GPU server is the pivot that turns a perimeter breach into a full data-exfiltration event. Defence in depth and micro-segmentation — cornerstones of the zero-trust posture we advise for network infrastructure — apply with equal force to AI workloads.

What You Should Do Right Now

Even if you are not a US federal agency subject to BOD 26-04, treat the August 20 deadline as your own. Here is the immediate action plan:

1. Inventory every Ray deployment immediately. Ray hides in unexpected places: developer workstations, Jupyter environments, Docker containers, Kubernetes pods, cloud-managed ML services, and vendor-bundled AI products. Run pip show ray across your estate, query container registries for images with Ray installed, and check CI/CD pipelines. Build a complete Ray asset inventory as a distinct asset class — it does not belong in the same bucket as web servers.
2. Upgrade to Ray 2.52.0 or later without delay. The fix is straightforward: pip install --upgrade ray and rebuild any Docker images or container base layers that pin an older version. Verify the upgrade propagated to every context — dev laptops, test environments, and production clusters alike.
3. Restrict Ray’s dashboard and API to localhost. If you cannot immediately patch, enforce a compensating control: ensure Ray’s dashboard (default port 8265) and API endpoints are bound only to 127.0.0.1, not to 0.0.0.0. Place a reverse proxy with authentication in front of any dashboard that must be shared across a team.
4. Block internet exposure of Ray ports. Audit cloud security groups, firewall rules, and NSGs for any inbound rules permitting access to Ray’s default ports (6379, 8265, 10001 range). No Ray port should be internet-accessible — ever.
5. Scan for indicators of ShadowRay 2.0 compromise. Look for unexpected XMRig processes, anomalous outbound traffic on GPU nodes, Ray job-submission logs with unfamiliar payloads, and environment-variable exfiltration attempts. GPU utilisation spikes with no scheduled training job are a reliable indicator of cryptomining abuse.
6. Apply micro-segmentation. Ray clusters should communicate only with explicitly authorised endpoints. Implement network policies that prevent Ray worker nodes from initiating outbound connections to arbitrary internet destinations or from reaching other internal subnets without explicit allow-listing.
7. Update your software inventory to flag AI framework versions. CVE-2025-62593 will not be the last critical vulnerability in an AI/ML framework. Treat Ray, LangChain, vLLM, LiteLLM, and similar packages with the same patching discipline you apply to web servers and network devices.

Frequently Asked Questions

Do I need to be running Ray as a server for this vulnerability to affect me?

No. Even a developer running Ray locally on a laptop is exposed. If a developer visits a malicious website — or simply loads a page with a malicious advertisement — while Ray is running locally, the DNS rebinding attack can redirect a browser fetch request to the local Ray API (127.0.0.1:8265) and execute arbitrary code on that laptop. In environments where developers have network access to shared Ray clusters, the impact extends to the entire cluster.

Does Ray 2.52.0 fully fix the DNS rebinding vulnerability?

Yes. The Ray 2.52.0 release addresses CVE-2025-62593 by implementing proper server-side controls that do not rely solely on the client-supplied User-Agent header for security decisions. The fix includes binding changes and authentication improvements to the job-submission API. Organisations should verify they are running 2.52.0 or a later patch release by running ray --version or pip show ray.

What data is at risk if a Ray cluster is compromised by ShadowRay 2.0?

Potentially everything that passes through Ray jobs: model weights and architectures (high-value intellectual property), training datasets, API keys and cloud credentials stored in environment variables, proprietary inference pipelines, and any data used in AI training or inference tasks. ShadowRay 2.0 actors have demonstrated capability to exfiltrate sensitive data alongside deploying cryptomining payloads.

Is this relevant for Indian enterprises not subject to CISA BOD 26-04?

Absolutely. CISA’s KEV catalog is the most authoritative real-world exploitation signal available globally — an entry means attackers are actively exploiting the flaw right now, not in theory. Indian enterprises running AI/ML workloads — whether in BFSI, manufacturing, pharma, e-commerce, or IT/ITeS — face the same threat actors and the same exploitation campaigns. CERT-In’s vulnerability-notification advisories also routinely reflect KEV additions. This is not a US-only concern; it is a global threat with active exploitation campaigns already in progress.

Act Before Attackers Reach Your GPU Nodes

CVE-2025-62593 is a sharp reminder that securing AI infrastructure is not a future concern — it is an immediate operational imperative. The sophistication of ShadowRay 2.0, the zero-day exploitation timeline of RondoDox, and the CISA-confirmed active exploitation all point to a threat that is mature, automated, and scaling. Every day an unpatched Ray instance remains network-accessible is a day attackers may be mining Monero on your NVIDIA GPUs, exfiltrating your model IP, or building their next DDoS campaign on your compute budget.

If you are uncertain about your organisation’s Ray exposure, your AI workload security posture, or how zero-trust principles should extend to your ML infrastructure, reach out for a complimentary security assessment. With over 30 years in cybersecurity and hands-on expertise in zero-trust architecture, network segmentation, and threat intelligence, Sanjay Seth and the P J Networks team can help you identify and close the gaps before attackers find them first.