Topic starter
07/06/2026 8:55 pm
TL;DR: ShadowRay 2.0 is an active global campaign that exploits Ray, the open-source AI framework, to seize exposed clusters, run cryptominers, hide persistence, and propagate malware through GitLab and GitHub updates, according to Oligo Security. The breach shows that AI workload exposure is now an identity and governance problem, not just a vulnerability issue, because self-managed compute still fails when isolation and runtime control are assumed rather than enforced.
Editorial analysis by NHI Mgmt Group, based on content published by Oligo Security: “ShadowRay 2.0: Active Global Campaign Hijacks Ray AI Infrastructure Into Self-Propagating Botnet”.
Key questions
Q: What breaks when Ray jobs APIs are exposed to the internet?
A: Exposed Ray jobs APIs turn orchestration into unauthorised execution.
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.
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.
Practitioner guidance
- Harden Ray exposure boundaries Place Ray dashboards, jobs APIs, and related orchestration endpoints behind private network controls and explicit allowlists.
- Audit workload fetch paths Review every place AI workloads pull code, binaries, or scripts from Git repositories, object storage, or release artifacts.
- Track runtime persistence signals Look for added SSH keys, masqueraded processes, cron-like re-execution, and payloads that survive takedown through alternate repositories.
Bottom line: ShadowRay 2.0 shows that exposed AI orchestration can be converted into persistent attacker control, not just a one-off vulnerability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 8:39 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ShadowRay 2.0 shows how AI workload exposure becomes botnet scale
This post was modified 3 days ago by NHI Mgmt Group