Thousands of servers holding AI workloads and network credentials have been hacked in an ongoing attack campaign aimed at Ray, an open source computing framework used by OpenAI, Uber, and Amazon.
Researchers say the campaign is the first known in-the-wild attack targeting AI workloads. The attacks have been active for at least seven months and show how exposed AI infrastructure can become a direct path to models, credentials, databases, and large amounts of computing power.
What the Ray attacks exposed
Ray is used to scale AI apps so large numbers of them can run efficiently at once. Those apps commonly run across huge clusters of servers, with a central dashboard used to display and control running tasks and apps.
That dashboard is central to the reported risk. One programming interface available through it, called the Jobs API, lets users send commands to the cluster through a simple HTTP request that requires no authentication.
In vulnerable deployments, the dashboard is exposed to the Internet. That means anyone who finds it can see a history of commands entered so far, which can reveal how a model works and what sensitive data it can reach.
According to the source article, compromised resources included AI production workloads, cryptographic password hashes, credentials to internal databases, and credentials or tokens for accounts on platforms including OpenAI, Hugging Face, Stripe, Azure, and Slack.
Why AI workloads are a high-value target
The campaign did not stop at basic server access. The attacks led to tampering with AI models, including during the training phase, where an attacker can affect model integrity.
Attackers also installed cryptocurrency miners on compromised infrastructure. That detail matters because AI clusters typically provide massive computing power, making them attractive for abuse beyond data theft.
Reverse shells were also installed. These text-based interfaces allow remote control of servers, giving attackers a way to continue operating inside compromised environments.
Oligo, the security firm that spotted the attacks, described the value of a compromised Ray production cluster in stark terms:
"When attackers get their hands on a Ray production cluster, it is a jackpot."
The reason is straightforward. A Ray cluster can combine sensitive company data, AI production workloads, credentials, and remote code execution. That mix gives attackers several ways to profit or expand access while staying difficult to detect.
The dispute over CVE-2023-48022
Last year, researchers from security firm Bishop Fox flagged the behavior as a high-severity code-execution vulnerability tracked as CVE-2023-48022.
Berenice Flores Garcia, a senior security consultant at Bishop Fox, wrote:
"In the default configuration, Ray does not enforce authentication. As a result, attackers may freely submit jobs, delete existing jobs, retrieve sensitive information, and exploit the other vulnerabilities described in this advisory."
Anyscale, the developer and maintainer of Ray, disputed the vulnerability. Anyscale officials said Ray has always been presented as a framework for remotely executing code and should be segmented inside a properly secured network.
The company wrote:
"Due to Ray’s nature as a distributed execution framework, Ray’s security boundary is outside of the Ray cluster. That is why we emphasize that you must prevent access to your Ray cluster from untrusted machines (e.g., the public Internet)."
Anyscale said the reported behavior in the jobs API was not a vulnerability and would not be addressed in a near-term update. The company also said it would eventually introduce a change to enforce authentication in the API as a future feature for defense-in-depth.
Why configuration became the central issue
The attacks highlight a practical security problem: a tool designed for distributed execution can become dangerous when reachable from untrusted machines.
Critics of Anyscale’s response pointed to repositories for deploying Ray in cloud environments that bind the dashboard to 0.0.0.0. That address is used to designate all network interfaces and to designate port forwarding on the same address.
One beginner boilerplate was available on the Anyscale website itself, according to the source article. Another publicly available vulnerable setup was also cited.
Critics also said Anyscale’s position that the reported behavior was not a vulnerability prevented many security tools from flagging attacks. That created a gap between how the behavior was categorized and how it was being abused in the wild.
An Anyscale representative said in an email that the company planned to publish a script that would let users easily verify whether their Ray instances are exposed to the Internet.
What Ray users should take from the campaign
The most immediate lesson is that exposed Ray clusters can place AI workloads, credentials, internal databases, and account tokens at risk. The reported attacks show that access to a dashboard is not merely visibility; through the Jobs API, it can become command execution.
Ray users should focus on whether their clusters are reachable from the public Internet and whether sensitive credentials are exposed through command histories or workloads. Oligo and Anyscale both list practices for locking down clusters, and Oligo provided indicators users can check to determine whether their instances have been compromised.
The broader implication is that AI infrastructure needs the same hard security boundaries as other production systems. When model training, internal credentials, and large-scale compute live together, a weak access boundary can turn one exposed service into a much larger incident.