ShadowRay: When Exposed AI Compute Clusters Became a Cryptomining Farm

In March 2024, the security firm Oligo Security disclosed a campaign it named ShadowRay: thousands of Ray clusters — the popular open-source framework for distributed AI workloads — exposed to the internet and, in many cases, actively exploited. What made the disclosure unusually instructive was not just the scale, but the argument that erupted over whether there was a vulnerability at all.

Ray, maintained by Anyscale, orchestrates the compute behind training and serving machine-learning models. Its Jobs API lets a client submit code to run across the cluster. Oligo's finding centred on CVE-2023-48022: that API accepts jobs without authentication, so anyone who can reach it over the network can execute arbitrary code on the cluster.

What the attackers got

Because these clusters exist to do heavy computation, the payoff for an intruder is immediate. Oligo reported that exploited clusters exposed exactly the things AI infrastructure hoards: GPU compute, models and training data, database credentials, and tokens for services such as OpenAI, Hugging Face, Slack, and cloud providers, alongside SSH keys. Observed payloads included cryptominers and reverse shells, and Oligo indicated some clusters had been under attacker control for months.

The dispute you must report fairly

Here is the part defenders should hold in mind. Anyscale's position is that this is expected behaviour, not a vulnerability: the Ray Jobs API is intentionally unauthenticated and is documented to run inside a trusted, isolated network. Because the vendor disputes it, CVE-2023-48022 carries a "disputed" tag. Both things are true at once — the framework is behaving as its maintainers intend, and thousands of real deployments exposed it to the open internet with catastrophic results.

That tension is the actual lesson. A component that is safe only inside a trusted network becomes dangerous the instant an operator, misunderstanding that assumption, binds it to a public interface. The security boundary lived in the deployment, not the code — and the documentation's assumption did not survive contact with how people actually run things.

The disputed status has a practical consequence defenders should internalise: you cannot wait for a patch that, by the maintainer's philosophy, is never coming. When a component's security model assumes network isolation and the vendor declines to add authentication, the responsibility to enforce that boundary is entirely yours — firewalling, network policy, and monitoring you own and maintain. It is also a broader signal about the AI stack's maturity. Much of the tooling data-science teams reach for was built for speed and internal experimentation, with security assumptions that made sense in a lab and turn dangerous the moment the workload is promoted to a cloud environment reachable from the internet. Treat every AI framework's default posture as insecure-until-verified, and read the documentation specifically for the sentence that says "only run this on a trusted network."

What defenders should take away

• Never expose Ray's dashboard or Jobs API to the internet. Keep it on a private network, behind authentication you add yourself, and firewall the relevant ports.
• Do not assume "trusted network" is true. If a component's safety depends on network isolation, verify that isolation with scanning, not with an assumption.
• Rotate what a compromised cluster would hold. Treat the API keys, cloud credentials, and SSH keys reachable from your ML infrastructure as high-value secrets with short lifetimes.
• Inventory your AI compute. Shadow clusters spun up by data-science teams are the ones most likely to be misconfigured and unmonitored.

ShadowRay is a story about a boundary that existed on paper and not in practice. Whether or not you call it a vulnerability, the exposure was real — and the clusters that got hit were, overwhelmingly, ones their owners did not realise were reachable. You cannot defend what you have not discovered.