200,000 Ray AI Clusters Exposed to CVE-2025-62593 RCE: CISA Deadline August 20

CVE-2025-62593 exploits two overlapping weaknesses in Ray's API security model: the absence of authentication on the Job API and an insufficient browser-origin check.

The Ray dashboard exposes a web-based Job API at /api/jobs and /api/job_agent/jobs/. These endpoints accept arbitrary Python or shell code submissions without requiring any credentials. Anyscale's original design assumed Ray would be deployed in isolated network environments and operated by trusted users, so no authentication gate was added to the API layer. The only defense against external browser access was a User-Agent header check requiring requests to start with "Mozilla."

DNS rebinding attacks bypass this check by convincing a victim's browser to make requests on the attacker's behalf. The attack proceeds in four steps. An attacker registers a malicious domain and sets a very short DNS TTL. The victim visits the attacker's page in Firefox or Safari, and the page begins executing JavaScript. The attacker's DNS server then re-resolves the same hostname to the Ray cluster's local IP address. On subsequent JavaScript requests, the browser believes it is communicating with the original domain, satisfying the same-origin policy, but the requests now reach the Ray cluster directly. The JavaScript sends a properly formed User-Agent header starting with "Mozilla," passing Ray's check, and the cluster executes the submitted job as the Ray process.

Attackers targeting directly internet-exposed Ray clusters skip the DNS rebinding step entirely and submit jobs directly to the unauthenticated API. This is the technique the ShadowRay 2.0 campaign uses against the 200,000 publicly exposed Ray servers. A single HTTP POST to /api/jobs with a bash payload is sufficient for full cluster compromise with no credentials or user interaction required.

The result in both cases is arbitrary command execution on the Ray head node and, through Ray's native job scheduling API, on every worker node in the cluster. The Langflow CVE-2026-9198 unauthenticated RCE followed an identical pattern of an AI framework API endpoint with no authentication gate, reinforcing this as a systemic category risk across the AI tooling ecosystem.

ShadowRay 2.0 is an active global campaign documented by Oligo Security in November 2025 that exploits exposed Ray clusters to build a self-replicating cryptocurrency mining botnet. The campaign operator, identified as IronErn440, has been active since at least September 2024, targeting over 200,000 publicly accessible Ray deployments across multiple continents.

The attack begins with passive reconnaissance. IronErn440 submits test jobs to /api/jobs/ using Ray's legitimate job API, triggering DNS and HTTP callbacks to interact.sh infrastructure at oast.fun to identify which Ray instances are alive and accessible. For confirmed targets, attackers submit multi-stage Bash and Python payloads that establish persistence and deploy the full attack toolkit.

Post-exploitation establishes four capabilities simultaneously. XMRig v6.16.4 mines Monero through pool.supportxmr.com on port 443 to blend mining traffic with HTTPS. The Rigel GPU miner targets NVIDIA CUDA devices. Sockstress, a TCP state exhaustion tool, transforms infected clusters into DDoS weapons targeting other mining pools. Ray's NodeAffinitySchedulingStrategy is then weaponized to enumerate all cluster nodes and pin malicious jobs to each one, spreading the infection laterally across the entire cluster without additional exploits.

To avoid detection, IronErn440 limits CPU usage to approximately 60% and hides GPU memory consumption from Ray's native monitoring. Malicious processes are renamed: XMRig runs as kworker/0:0 (masquerading as a Linux kernel worker), .python3.6 (hidden with a leading dot), and dns-filter (appearing as a system service). A competing miner elimination script also runs, killing any XMRig processes not connected to IronErn440's preferred pool and blocking competing pools via /etc/hosts and iptables.

One compromised cluster documented by Oligo contained NVIDIA A100 GPUs with an annual on-demand value exceeding three million dollars. Attackers accessed and exfiltrated a 240-gigabyte compressed archive from this cluster containing source code, AI model weights, training datasets, and database credentials. Stolen AI model weights represent competitive intelligence worth months of GPU training compute. The LLMjacking AI compute theft campaign documented earlier this year followed a similar pattern, though targeting API keys rather than direct cluster access.

Compromised Ray clusters show characteristic signs across four categories. Check all of them before and after patching. If a cluster was exposed before today's CISA KEV announcement, treat it as potentially compromised until you have completed a full forensic sweep.

Network indicators: Block outbound connections to the following IPs at your perimeter firewall immediately. Any DNS query for pool.supportxmr.com or eu.zano.k1pool.com from a Ray cluster node confirms active cryptocurrency mining. Block both mining pool domains at your DNS resolver in addition to the firewall.

Process masquerade indicators: Run ps aux on each Ray worker node and search for processes named kworker/0:0, dns-filter, and .python3.6. Legitimate Linux kernel worker threads do not use static notation in the format kworker/0:0 under standard scheduling. Legitimate Python processes do not prefix their name with a dot. Any hit on these names warrants immediate process termination and forensic review of the executable path.

Persistence indicators: Run crontab -l on all Ray nodes and examine /etc/cron.d/ for entries that download and pipe shell scripts from GitHub or GitLab repositories. IronErn440's cron persistence executes every 15 minutes. Also check .bashrc for injected commands and systemd unit files under /etc/systemd/system/ for unfamiliar services.

Data exfiltration indicators: Review recent large archive creation events on Ray head nodes. Check cloud storage (S3, GCS, Azure Blob) access logs for high-volume data reads that do not match normal application traffic patterns. Review MySQL and PostgreSQL access logs for query patterns inconsistent with your application's normal behavior.

No CVE-specific Sigma rule for CVE-2025-62593 exists in the SigmaHQ library yet. The vulnerability was added to the CISA KEV catalog today, and community rules for AI framework CVEs typically lag the disclosure date by three to six weeks. The two rules below target the post-exploitation behavior that is consistent across ShadowRay 2.0 infections: outbound DNS queries to Monero mining pools and suspicious cron job modifications on Linux nodes.

The Monero mining pool DNS rule is status:stable and operates on DNS query logs. Deploy it in your SIEM against DNS resolver logs or network packet capture from Ray cluster nodes. This rule explicitly covers pool.supportxmr.com, the primary mining pool used by ShadowRay 2.0.

The Linux cron job rule requires process execution telemetry from Ray nodes. Enable auditd or deploy osquery to capture execve syscalls for crontab process creation. ShadowRay 2.0's 15-minute cron persistence generates consistent crontab activity; any crontab invocation from a Ray cluster node is a high-priority signal requiring immediate investigation.

The WAF rules below target CVE-2025-62593 at the HTTP layer. The exploit arrives as an unauthenticated POST or GET to /api/jobs or /api/job_agent/jobs/ endpoints. Deploy any reverse proxy or WAF in front of Ray dashboards in count or log mode first to establish a legitimate traffic baseline before switching to block mode.

Apply the following steps in order. The patch is the critical action. All other steps harden against re-exploitation and address potential existing compromise.

CVE-2025-62593 represents a systemic category of risk that is accelerating as AI infrastructure scales: compute APIs designed for trusted networks deployed without authentication in environments that are no longer isolated.

Ray's design decision to trust its network environment made sense when distributed computing clusters were isolated research infrastructure. Modern AI development workflows do not match that assumption. Developers run Ray locally on laptops connected to corporate networks, researchers spin up Ray clusters on cloud instances with default security group configurations, and enterprises deploy Ray for production AI serving with management interfaces accessible for operational convenience. The 200,000 exposed Ray instances BitSight identified in March 2026 represent a 10x increase from the 2024 baseline, tracking exactly with AI adoption growth.

The compute and data value in a Ray cluster is substantial. OpenAI, major financial institutions running quantitative model backtesting, and healthcare organizations running drug discovery AI all use Ray at scale. NVIDIA A100 clusters routinely exceed three million dollars in annual on-demand compute cost. AI model weights represent months of training time and competitive intelligence. The ShadowRay 2.0 campaign documented by Oligo monetizes this directly: stolen GPU cycles for cryptocurrency, stolen model weights for IP theft or competitive intelligence, stolen database credentials for further access.

The federal August 20 deadline signals assessed exploitation risk in the immediate term. The 48-hour window CISA set is among the shortest deadlines in the KEV catalog this year, reflecting confirmed active exploitation by multiple threat actors with public exploit code available. Every organization running Ray, regardless of federal affiliation, should treat the August 20 date as an operational deadline and complete the patch and network isolation steps today.