CISA added CVE-2025-62593, a critical remote code execution flaw in the Ray distributed AI/ML compute framework, to its Known Exploited Vulnerabilities catalog on August 17, 2026, citing confirmed in-the-wild exploitation. The bug lets an attacker achieve unauthenticated RCE against a developer’s local machine through nothing more than a visit to a malicious web page in Firefox or Safari — no direct network exposure required. Federal Civilian Executive Branch agencies have until August 20, 2026 to remediate.

What happened

Ray, maintained by Anyscale, is the Python-native distributed compute engine underpinning a large share of production AI training and inference workloads — it’s the orchestration layer behind Kubernetes-based ML platforms, autoscaling GPU clusters, and serving stacks for frameworks like vLLM. Ray has a well-documented history of shipping without authentication on its control-plane HTTP APIs, on the stated assumption that clusters only ever run on trusted internal networks. That assumption produced the original ShadowRay campaign in 2024 (CVE-2023-48022), where attackers scanned the internet for exposed Jobs API endpoints on port 8265 and ran arbitrary code directly.

CVE-2025-62593 is a distinct, newer flaw in the same trust model, but it removes the precondition of direct network exposure entirely. Ray’s dashboard and job-submission APIs (/api/jobs, /api/job_agent/jobs/) attempted a lightweight defense: reject requests unless the User-Agent header starts with Mozilla, on the theory that this blocks non-browser tooling from reaching the API over the loopback interface. The fetch specification, however, allows a page to set an arbitrary User-Agent value, and combined with a DNS rebinding attack, a malicious web page (or malvertisement) can rebind a hostname from an attacker-controlled IP to 127.0.0.1 mid-session, then issue authenticated-looking, browser-originated requests straight into the victim’s local Ray API. A developer running Ray locally who simply browses to a booby-trapped site — no phishing click, no download — hands the attacker code execution on their machine.

Technical details

  • CVE: CVE-2025-62593, CVSS 9.4 (Critical)
  • Component: Ray dashboard/job-agent HTTP APIs (ray-project/ray), GHSA-q279-jhrf-cc6v
  • Affected versions: Ray prior to 2.52.0
  • Vector: DNS rebinding + browser-spoofed User-Agent header bypassing the Mozilla-prefix check, reaching the loopback-bound job-submission API from a malicious webpage
  • Impact: Unauthenticated remote code execution on any host running a vulnerable Ray instance, triggered purely by the victim’s browser visiting attacker-controlled content
  • Fix: Ray 2.52.0

The vulnerability was publicly disclosed November 26, 2025. BitSight researchers tracking the RondoDox DDoS botnet found operators had already incorporated it into their exploit arsenal two days before public disclosure, indicating either a leaked advisory or independent discovery by the threat actor. Since then, unpatched Ray deployments — clusters exposing the same underlying API surface directly to the internet, not just to a local browser — have also been targeted by ShadowRay 2.0, a self-propagating campaign that hijacks NVIDIA GPU-equipped Ray clusters into a cryptocurrency-mining botnet. Reporting on that campaign has put the number of internet-exposed, vulnerable Ray servers scanned by attackers above 230,000.

Impact

This affects two overlapping populations: ML engineers and platform teams running Ray as a local development tool (vulnerable to the browser/DNS-rebinding path), and organizations running Ray clusters with any control-plane exposure beyond a fully isolated network (vulnerable to direct exploitation and absorption into ShadowRay 2.0). Ray’s own security posture — years of resisting adding authentication to these endpoints on the grounds that “security must be enforced outside the cluster” — means the population of exposed, unpatched instances stays large by design rather than by accident. Given RondoDox’s pre-disclosure weaponization and the ongoing GPU-cryptomining campaign, treat any Ray deployment reachable from an untrusted network, and any developer workstation running Ray locally, as actively targeted.

Mitigation

  • Upgrade to Ray 2.52.0 or later immediately, on both cluster nodes and developer workstations.
  • Never expose the Ray dashboard or job-submission ports (default 8265 and related job-agent ports) to the public internet; bind them to localhost or an internal-only network segment, and enforce network policy at the Kubernetes/cloud security-group layer regardless of patch status.
  • For developers running Ray locally: patching removes the vulnerable code path, but as defense in depth, avoid running Ray dashboards while browsing untrusted sites, and consider a host firewall rule blocking browser processes from reaching the Ray API port.
  • Audit existing clusters for indicators of ShadowRay 2.0 compromise — unexpected GPU utilization, unfamiliar Ray jobs, outbound connections to unfamiliar mining pools.
  • FCEB agencies must remediate per CISA’s binding operational directive by August 20, 2026; all organizations running Ray should treat that as the practical deadline.

Sources