ShadowRay 2.0 shows how AI workload exposure becomes botnet scale

At a glance

What this is: This is an analysis of ShadowRay 2.0, where exposed Ray AI workloads are being used to build a self-propagating botnet that hides mining, persistence, and update delivery inside ordinary-looking infrastructure flows.

Why it matters: It matters because identity teams now have to treat AI workload exposure as a governance problem as much as a patching problem, especially where runtime control, isolation, and secret handling were assumed rather than enforced.

Context

ShadowRay 2.0 is a Ray AI workload exposure problem that becomes an identity and governance problem once attackers can reach orchestration endpoints, reuse exposed runtime privileges, and move from one cluster to the next. The key failure is not just that a vulnerability exists, but that the surrounding deployment model assumes trusted network placement and safe runtime behavior that are not actually present.

In this campaign, exposed AI infrastructure is being used as operational substrate for mining, persistence, payload delivery, and lateral propagation. For IAM and NHI practitioners, that means workload identity, secrets, and service access controls cannot be treated as separate from the security of the AI platform itself.

The article shows an atypical escalation pattern in the sense that the exposed control plane is not merely a foothold, but the means of repeated malware delivery and botnet expansion.

Key questions

Q: What breaks when Ray jobs APIs are exposed to the internet?

A: Exposed Ray jobs APIs turn orchestration into unauthorised execution. Attackers can submit work that the platform itself carries out, which means the trust boundary is no longer the application user but the network placement and access control around the cluster. Once that boundary is public, discovery, payload delivery, and persistence can all happen through the same surface.

Q: Why do exposed AI workloads create botnet risk instead of only mining risk?

A: Because the attacker can use the workload as a reusable execution node, not just as a CPU source. In this campaign, the same compromised cluster supported mining, persistence, payload updates, and continued propagation. That means the security outcome is platform abuse with lifecycle persistence, not a one-time cryptomining event.

Q: How do security teams detect compromise in AI clusters beyond a miner binary?

A: Look for runtime behaviours that indicate control, not just payload type. SSH key insertion, masqueraded processes, repeated pull-based updates, reverse shells, and resource patterns that do not match the declared workload are stronger signals. A cluster can be deeply compromised even when the visible malware is renamed or throttled.

Q: What should teams do when an AI orchestration platform depends on a trusted network?

A: Treat that dependence as a security assumption that must be explicitly validated, not implied. If the platform is reachable outside the intended boundary, the model of “safe because it is internal” no longer holds. The practical response is to redesign access, execution, and secret handling around hostile-network assumptions.

Technical breakdown

How exposed Ray jobs enable remote control

Ray exposes a jobs API and related dashboard surfaces that can accept submitted work and execute it in a distributed AI environment. When those surfaces are reachable from the internet, an attacker does not need to “break in” through a traditional user session. They can submit commands that the platform itself will carry out, turning orchestration into execution. In this campaign, the exposed endpoint became the initial control surface, and automated discovery via callback infrastructure helped identify targets at scale. Practical implication: restrict Ray access to trusted networks and treat the jobs API as a privileged execution surface.

Practical implication: restrict Ray access to trusted networks and treat the jobs API as a privileged execution surface.

Why persistence and payload updates matter in AI workload abuse

The campaign did not stop at a single compromise. Attackers used GitLab and later GitHub to distribute and update payloads, turning ordinary developer infrastructure into a malware delivery path. That matters because AI workload abuse often combines runtime compromise with external update channels, letting operators change miner behavior, evade detection, and re-seed infected nodes without re-exploiting the original target. In identity terms, the problem extends beyond access into ongoing authorization to update code, fetch binaries, and execute scripts inside exposed environments. Practical implication: separate runtime trust from content distribution trust and audit where workloads fetch executable material from.

Practical implication: separate runtime trust from content distribution trust and audit where workloads fetch executable material from.

How cryptomining becomes a wider botnet capability

ShadowRay 2.0 uses mining as the visible payload, but the operational shape is broader. The actors terminate competing miners, mask processes, limit resource use to reduce detection, and add SSH keys for continued access. That mix shows a platform compromise that behaves like a botnet rather than a single-purpose miner. In NHI terms, the same exposed workload can carry attacker-controlled secrets, persistent access paths, and execution channels that survive beyond the first payload. Practical implication: measure compromise by runtime behavior and access persistence, not by whether a miner binary is present.

Practical implication: measure compromise by runtime behavior and access persistence, not by whether a miner binary is present.

Threat narrative

Attacker objective: The objective is to monetize exposed AI workloads by turning them into a distributed botnet that mines cryptocurrency, persists on host systems, and can be reused for broader malicious operations.

1. Entry occurs when attackers discover internet-exposed Ray dashboards and jobs APIs through automated callback-based reconnaissance.
2. Credential and execution access follow when the exposed Ray surface accepts attacker-submitted jobs and runs payloads inside the cluster.
3. Escalation and persistence emerge as the operators add SSH keys, disguise processes, and continuously refresh payloads through GitLab and GitHub releases.
4. Impact is the conversion of compromised Ray clusters into a self-propagating cryptomining and malware-delivery botnet that can also support exfiltration and DDoS activity.

Breaches seen in the wild

• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposed AI orchestration is now an identity boundary, not only a vulnerability surface. When Ray jobs APIs are reachable from the internet, the platform itself becomes the actor that executes attacker-supplied work. That shifts the governance question from whether a flaw exists to whether runtime access, trust placement, and network exposure were ever truly bounded. Practitioners should treat AI workload reachability as part of identity design, not as an infrastructure afterthought.

Strictly-controlled network environment is the assumption that failed here. That assumption was designed for deployments where Ray stays inside a trusted perimeter and execution requests come only from approved operators. It fails when the same interface is exposed broadly and automated discovery can turn it into a public execution service. The implication is that many AI workload programmes are relying on placement assumptions that no longer hold once real-world operators ignore the guidance.

ShadowRay 2.0 is a named example of identity blast radius inside AI infrastructure. Once the workload can fetch payloads, run them, retain access, and pivot into adjacent systems, the compromise is no longer isolated to the original cluster. The same path also creates exposure to secrets, database access, and downstream service abuse. Practitioners should map the blast radius of exposed AI runtimes across workload identity, secrets, and update channels.

DevOps-style malware delivery collapses the line between software distribution and attack operations. The use of GitLab and GitHub to iterate payloads, push updates, and relaunch after takedown shows that the attacker’s control plane looks increasingly like normal release engineering. That makes provenance, repository trust, and execution authorization part of the identity problem. Practitioners should assume that the delivery channel can be weaponized as readily as the runtime itself.

Runtime visibility must sit above the platform’s own monitoring claims. The campaign hid GPU use, limited CPU consumption, and disguised processes as legitimate services, which means reliance on native UI signals will understate compromise. NHI governance for AI infrastructure has to verify what is actually executing, what credentials are in memory, and what external sources can influence the workload. Practitioners should move toward runtime evidence rather than configuration intent.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

AI workload exposure now behaves like an identity governance issue: if an orchestration layer can execute arbitrary jobs, then reachability, authorization, and runtime trust become one control problem rather than three separate ones. Programmes that still split cloud posture from identity governance will miss the blast radius created by exposed AI runtimes.

ShadowRay 2.0 sharpens the case for workload identity discipline in AI infrastructure: the same exposed environment can leak secrets, spawn persistence, and accept attacker-controlled updates. Teams should map where AI workloads authenticate, where they fetch executable content, and where those trust decisions are currently inherited from infrastructure defaults instead of explicit governance.

For practitioners

• Harden Ray exposure boundaries Place Ray dashboards, jobs APIs, and related orchestration endpoints behind private network controls and explicit allowlists. Do not rely on the assumption that “trusted environment” placement will be preserved by default.
• Audit workload fetch paths Review every place AI workloads pull code, binaries, or scripts from Git repositories, object storage, or release artifacts. Block unauthorised update channels and require provenance for executable content.
• Track runtime persistence signals Look for added SSH keys, masqueraded processes, cron-like re-execution, and payloads that survive takedown through alternate repositories. These are stronger indicators of cluster compromise than a single miner hash.
• Reduce secret exposure inside AI jobs Assume exposed jobs may reveal environment variables, database credentials, and cloud keys. Move secrets out of job context wherever possible and revoke any credentials that may have been mounted in compromised workloads.
• Correlate execution with resource abuse Alert when AI workloads spawn reverse shells, unusual miners, or sustained high-GPU usage that conflicts with the expected job profile. Treat unusual compute consumption as a governance signal, not only an operations anomaly.

Key takeaways

• ShadowRay 2.0 shows that exposed AI orchestration can be converted into persistent attacker control, not just a one-off vulnerability.
• The campaign combines automated discovery, payload delivery, mining, and credential exposure, which is why the blast radius extends beyond a single cluster.
• Security teams need to govern AI workload reachability, execution trust, and secret exposure as one operational domain.

Key terms

• AI Workload Exposure: AI workload exposure is the condition where orchestration, execution, or management surfaces for AI systems are reachable outside the intended trust boundary. In practice, it creates a path from public reachability to code execution, secret access, and persistent control if network placement and authorization are not tightly governed.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Botnet Propagation: Botnet propagation is the repeated spread of attacker-controlled execution across multiple hosts or clusters using automated persistence and update mechanisms. In AI workload incidents, propagation can happen through orchestration surfaces, repository-based payload delivery, and reused secrets rather than traditional malware-only channels.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.