ShadowRay 2.0: The Self-Propagating Botnet Hijacking AI Clusters

Researchers from Oligo Security presented findings at Black Hat USA 2026 this week that put a number on how badly the AI compute layer is being exploited: over 200,000 Ray servers are exposed to the internet with no authentication, and a significant portion of them are already compromised and participating in a self-propagating botnet. The campaign, ShadowRay 2.0, uses Ray’s own orchestration capabilities to spread between clusters, harvests credentials and data, mines cryptocurrency, and maintains persistence across reboots through mechanisms that blend into legitimate infrastructure.

The name is a sequel for a reason. The original ShadowRay campaign exploited the same underlying issue — CVE-2023-48022, an unauthenticated access flaw in Ray’s Jobs API — but operated at smaller scale and with less sophisticated persistence. ShadowRay 2.0 adds the self-replication component and has expanded the exposed surface roughly tenfold.

What Ray Is and Why This Is a Problem

Ray is an open-source framework for distributed Python computing, built for scaling machine learning workloads across nodes. Teams use it to run LLM training, distributed inference, and increasingly, multi-agent systems. It’s been described as “the Kubernetes of AI” — a reasonable analogy for its role in AI infrastructure.

The issue is that Ray was designed for trusted internal environments. Its dashboard runs on port 8265. Its Jobs API accepts job submissions without credentials. This is fine on a closed internal network. On the internet, it’s an open door: anyone who can reach the port can submit arbitrary Python code to execute across the cluster.

The vulnerability CVE-2023-48022 formalised this as a security finding back in 2023. Three years later, Oligo found more than 200,000 Ray servers still reachable from the public internet.

How ShadowRay 2.0 Operates

The infection chain starts with OAST-based scanning — attackers use interaction logging services like interact.sh to identify which IP addresses host exposed Ray dashboards. Discovery payloads are sprayed at internet-facing ranges, and confirmed responses are added to the target list.

Execution enters through the Jobs API. Ray accepts job submissions as Python code, which runs with the permissions of the Ray worker process. Attackers submit LLM-generated multi-stage bash and Python payloads that establish a reverse shell, install persistence, and set the cluster to work.

The worm mechanism uses Ray’s own scheduling primitives. The malware deploys itself across all nodes in a cluster via NodeAffinitySchedulingStrategy, Ray’s legitimate mechanism for placing jobs on specific hardware. Each node in the cluster gets infected. The newly compromised nodes then begin their own scanning and exploitation cycles, turning every victim into an attacker.

Persistence is multi-layered: cron jobs re-download and execute scripts from GitHub or GitLab every 15 minutes, systemd services disguised as dns-filter and health-monitor survive reboots, and SSH keys are injected for direct access independent of Ray.

What Gets Stolen and What Gets Mined

The payload has a financial motive at its core: XMRig miners targeting Monero pools are deployed across compromised GPU clusters. Resource usage is capped at roughly 60% to avoid triggering performance alerts while still generating meaningful mining revenue from expensive hardware like NVIDIA A100 clusters.

But the operation goes beyond mining. The campaign has exfiltrated 240GB of compressed source code, AI models, and datasets from compromised environments. Cloud credentials stored in environment variables — AWS keys, GCP service accounts, access tokens — are harvested for lateral movement into broader cloud tenants. MySQL credentials are extracted from environment configuration. SSH keys give persistent access to anything the cluster can reach on internal networks.

Competitive suppression measures are included: the malware terminates known rival miners, blocks mining pool connectivity for competitors via firewall rules, and manipulates /etc/hosts to prevent rival infrastructure from resolving. This suggests the operators are aware they’re contending for already-compromised machines.

The Visibility Gap

Only 23% of security leaders report full visibility into AI agents and compute infrastructure operating in their environments, according to data cited at Black Hat. ShadowRay 2.0 is a direct consequence of that gap. Ray clusters are deployed by data science and ML engineering teams; they often sit outside the standard asset management and vulnerability scanning perimeter that enterprise security teams maintain.

The configuration problem — exposing Ray’s unauthenticated API to the internet — is well documented and three years old. The fact that over 200,000 servers remain exposed suggests this is not a patching problem but a visibility and ownership problem: the teams deploying these clusters either don’t know they’re exposed or don’t know security teams exist to help them check.

References

• Oligo Security — ShadowRay 2.0: Attackers Turn AI Against Itself in Global Campaign
• Forkast — Black Hat USA 2026 Signals Agent Exploitation Has Become Its Own Infrastructure Discipline
• SecurityWeek — Two-Year-Old Ray AI Framework Flaw Exploited in Ongoing Campaign
• Straiker — AI Agents Take Center Stage at Black Hat USA 2026