Ray AI Framework CVE Hits CISA KEV — Patch GPU Clusters by Aug 20

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · Securing AI infrastructure for US and EU engineering teams

The short answer

What is Ray, and why are teams running it?

Ray is an open-source, Python-native distributed computing framework designed to scale AI and machine learning workloads across clusters of machines. Teams building AI/ML systems at scale use Ray to parallelize training runs, host inference endpoints, orchestrate reinforcement learning pipelines, and coordinate large-scale data preprocessing. It is the runtime backbone behind projects like vLLM, RLlib, and many enterprise AI platforms, and it integrates natively with PyTorch, LangChain, and Hugging Face transformers.

The same properties that make Ray appealing for AI workloads — fast cluster management, rich job scheduling APIs, and browser-accessible dashboards — also mean a compromised Ray instance hands an attacker exactly what they want: a pool of high-performance GPUs running in a trusted internal network, pre-connected to training data, model weights, and downstream services.

The flaw: no auth by design, now weaponized

CVE-2025-62593 is not a one-line coding mistake. It reflects a longstanding architectural decision: Ray's critical management endpoints — /api/jobs and /api/job_agent/jobs/ — expose unauthenticated job submission by design, on the assumption that Ray runs inside isolated, trusted networks. The Ray development team has historically treated network-level isolation as the security boundary, not application-layer authentication.

The attack chain exploits this in two stages. First, a DNS rebinding technique: an attacker hosts a malicious web page whose DNS record initially resolves to the attacker's server, then switches to resolve to 127.0.0.1 (localhost) after the browser caches the record. Once the browser re-resolves, it treats the malicious page as the same origin as the victim's local Ray dashboard and submits arbitrary job payloads via the unauthenticated API. Second, Ray attempted to defend against this with a User-Agent check — rejecting requests where the User-Agent header does not start with “Mozilla” — but the Fetch specification allows JavaScript to set this header, defeating the guard entirely. Affected browsers include Firefox and Safari.

Direct internet exposure creates an even simpler path. If a Ray cluster's dashboard (default port 8265) or job API is reachable without a firewall or authentication proxy, an attacker needs no browser involvement at all: a single POST to /api/jobs with a crafted payload executes arbitrary code on the cluster.

ShadowRay 2.0: self-spreading GPU botnet

The real-world exploitation is not theoretical. A threat campaign tracked as ShadowRay 2.0 has been incorporating CVE-2025-62593 since before its public disclosure in November 2025. BitSight researchers reported in March 2026 that actors behind the RondoDox DDoS botnet had weaponized the vulnerability within two days of disclosure, and the campaign has grown since then.

The infection chain is straightforward and automated. Once an attacker submits a job to an exposed Ray cluster, they install the XMRig cryptocurrency miner on every node with GPU capacity. The miner disguises its processes as legitimate Linux kernel worker threads and caps CPU usage at around 60% to reduce the chance of triggering performance alerts. It scans for competing miners on the same host and terminates them. The campaign also includes checks for the victim's geographic location — machines in China receive a different malware variant — indicating an organized operation with selective targeting. Compromised clusters are enrolled into the RondoDox DDoS infrastructure, compounding the harm beyond financial losses from stolen GPU time.

The practical consequence for engineering teams is that an unpatched Ray cluster is likely already under active scanning. Internet-facing instances with no authentication are being probed continuously, and internal clusters that a developer could reach from a compromised developer machine are not safe either.

What it means for US & EU AI teams

The immediate operational risk is GPU spend and workload disruption. A miner running at 60% GPU load on a training cluster can add thousands of dollars a day to cloud bills while silently degrading the jobs it was supposed to be running. It also contaminates any model checkpoints or data pipelines that share the same storage, and it may exfiltrate API credentials or model weights stored in the cluster environment.

For teams in regulated industries, the story goes further. A compromised cluster that processes personal data for training — common in HealthTech, FinTech, and retail personalization — may trigger breach-notification obligations under the EU GDPR (72-hour window) and a growing set of US state privacy laws. For financial entities in scope for the EU's DORA regulation, a training-cluster compromise can qualify as an ICT-incident requiring reporting to national competent authorities, with potential fines for delayed disclosure. US teams under HIPAA or SOC 2 commitments face similar scrutiny if patient data or customer records were reachable from the cluster environment.

The structural takeaway is the same one that surfaced with Langflow and other AI tooling: the infrastructure used to build AI systems has become as valuable a target as production systems, because it combines high-value compute with embedded credentials and privileged access to data. Ray clusters are not internal development toys; they are production-grade critical infrastructure.

What to do before August 20

The FCEB deadline is a useful forcing function even for non-federal teams. The window is short enough to focus minds without being impossibly tight.

1. Upgrade Ray to 2.52.0 or later. This is the only complete fix. Version 2.52.0 adds authentication to the previously unprotected job API endpoints. Pin the version in your cluster configuration and redeploy.
2. Block Ray dashboard and API ports from public and untrusted networks immediately. While you prepare the upgrade, add firewall rules or cloud security group rules to block inbound traffic on port 8265 (dashboard) and any other Ray service ports from everything except trusted internal CIDR ranges. This closes the direct exploitation path while the patch is in flight.
3. Check your GPU utilization and cloud spend right now. A sudden floor of unexplained GPU load, unfamiliar processes running as kernel workers, or a spike in cloud compute costs over the past several weeks may indicate prior compromise. Review cluster logs for unexpected job submissions to /api/jobs or /api/job_agent/jobs/.
4. Rotate credentials that may have been accessible from the cluster. If the cluster had access to cloud provider credentials, object storage keys, model registry tokens, or database connection strings, rotate them. A compromised job can read environment variables and mounted secrets.
5. Audit your AI tooling network exposure broadly. Ray is the acute case today, but the underlying pattern — AI frameworks with no authentication, deployed too close to the network edge — affects Jupyter notebooks, vector database dashboards, model serving endpoints, and LLM orchestration platforms. Inventory everything, and put it behind authentication and network controls.

Frequently asked questions

Sources

CISA — Adds One Known Exploited Vulnerability to Catalog (August 17, 2026)
The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE
Oligo Security — ShadowRay 2.0: Active Global Campaign Hijacks Ray AI Infrastructure Into Self-Propagating Botnet
Sophos AI Security 2026 Report — AI Identities as the Fastest-Growing Exposed Attack Surface