Attackers are actively abusing a critical remote code execution (RCE) vulnerability CVE-2023-48022 in the popular Ray framework to hijack artificial intelligence (AI) clusters and assemble a self-propagating botnet dubbed ShadowRay 2.0. Research by Oligo Security shows that compromised Ray clusters are being weaponized for cryptomining, data theft, distributed denial-of-service (DDoS) attacks and automated internet-wide scanning.
Ray framework and CVE-2023-48022: why unsecured AI clusters are at risk
Ray, developed by Anyscale, is an open-source framework widely used for distributed Python workloads, including machine learning, large-scale data processing and high-performance computing. According to Anyscale, Ray underpins infrastructure at major technology companies such as Uber, Amazon, Spotify, LinkedIn and OpenAI, where it supports training of large models like ChatGPT.
The issue tracked as CVE-2023-48022 has a CVSS score of 9.8, categorizing it as critical. The flaw stems from the fact that Ray’s Jobs API can accept and execute arbitrary commands without any authentication. If a Ray cluster is reachable over the network, an attacker can send a crafted request and execute arbitrary code, effectively gaining full control of the cluster.
When the issue became public, Anyscale stated that Ray was designed to operate only in a “tightly controlled network environment” and that the lack of authentication was an intentional architectural choice. Because of this stance, parts of the industry initially did not treat the problem as a traditional vulnerability, and some vulnerability databases did not list it. As a result, CVE-2023-48022 became a “shadow vulnerability” for many security teams, despite the high practical risk.
ShadowRay 2.0: how attackers compromise and spread across Ray AI clusters
AI-generated payloads and automated exploit chains
Oligo Security attributes the current ShadowRay 2.0 activity to an operator using the alias IronErn440. The attacker relies heavily on AI-generated payloads to compromise Ray clusters, visible through tell-tale code patterns: verbose and unnecessary docstrings, unused echo commands, repetitive comments and characteristic error-handling structures commonly produced by code-generation tools.
Once a Ray node is exposed, the attacker delivers multi-stage bash and Python payloads via the Jobs API. The malware then abuses Ray’s own orchestration mechanisms to fan out automatically across all nodes in the cluster. This turns the AI infrastructure into a tightly coupled botnet with centralized command-and-control behavior built on top of Ray’s distributed execution model.
GitLab and GitHub as a criminal DevOps pipeline
Researchers distinguish two main ShadowRay 2.0 waves. The first, ending around 5 November, used GitLab to host malicious payloads. The second, ongoing wave that started on 17 November, pivoted to GitHub. When malicious repositories were taken down, new ones appeared quickly, mirroring a mature DevOps-style workflow where attackers iterate, deploy and update their toolset at high speed.
The exposure landscape is deteriorating. Oligo Security now observes more than 230,000 Ray servers accessible from the public internet, compared with only a few thousand at the start of the earlier campaigns. This dramatic growth in exposed instances significantly increases the potential attack surface for ShadowRay 2.0 and future copycat operations.
ShadowRay malware capabilities: cryptomining, data theft and worm-like spread
Monero cryptomining and XMRig stealth techniques
A primary use of hijacked resources is Monero (XMR) cryptomining using the popular XMRig miner. To reduce detection, the miner typically caps CPU usage at around 60% and masquerades as legitimate processes such as dns-filter. The malware also terminates competing miners and sabotages rival operations by modifying /etc/hosts and iptables rules to block other mining pools.
Data exfiltration, DDoS with Sockstress and persistence
Through multiple reverse shells, attackers gain interactive access to compromised systems and can harvest high-value data: MySQL credentials, access tokens, cloud keys, proprietary AI models and source code. On one compromised server, researchers identified approximately 240 GB of model artifacts and datasets, illustrating the potential scale of intellectual property theft in AI environments.
ShadowRay 2.0 also integrates the Sockstress tool to launch DDoS attacks by opening large numbers of TCP connections via raw sockets, exhausting target resources. In parallel, infected Ray clusters scan the internet for other vulnerable Ray instances, giving the campaign worm-like self-spreading behavior.
For persistence, the malware modifies cron and systemd configurations to ensure automatic startup and schedules periodic (every 15 minutes) checks against GitHub for updated payloads. This design allows operators to roll out new malware versions rapidly without manual access to each compromised node.
How to protect Ray deployments from ShadowRay and similar campaigns
In the absence of a native patch that adds robust authentication to the Jobs API, CVE-2023-48022 remains a serious risk for any organization running Ray in production or research environments. With hundreds of thousands of Ray endpoints now visible online, the probability of compromise, data exfiltration and unauthorized consumption of compute resources continues to rise.
Oligo Security and Anyscale recommend at least the following defensive measures for organizations operating Ray:
- Network isolation of Ray clusters. Deploy Ray exclusively on internal or segmented networks, avoiding any direct exposure to the public internet. Use VPNs and Zero Trust access controls for administrative connections.
- Strict traffic filtering. Protect Ray nodes with firewalls and access control lists (ACLs), allowing connections only from trusted IP ranges and services.
- Protect the Dashboard and Jobs API. Add strong authentication and authorization in front of the Ray Dashboard (default port 8265) and Jobs API, ideally placing them behind a reverse proxy or API gateway that enforces additional checks.
- Continuous monitoring and incident response. Monitor for abnormal CPU/GPU utilization, unusual outbound connections, traffic spikes and suspicious Jobs API submissions. Unknown or masquerading processes – especially those resembling system services – should be investigated and contained quickly.
- Exposure management. Regularly scan on-premises and cloud infrastructure for unintentionally exposed Ray instances or undocumented clusters that could serve as entry points for ShadowRay 2.0 and similar threats.
ShadowRay 2.0 underscores how quickly adversaries can combine AI-generated code, DevOps practices and mainstream AI frameworks to automate large-scale attacks. Organizations building or operating AI and high-performance compute stacks should revisit their threat models, harden network segmentation and introduce additional authentication layers around orchestration APIs. Proactively closing exposed entry points and investing in anomaly detection across AI workloads will be critical to ensuring that powerful compute clusters do not become the backbone of the next global botnet.
