CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog today with a two-day remediation deadline for federal agencies. The vulnerability is in Ray, the open-source AI compute framework with over 40,000 GitHub stars and ten million weekly downloads.
The bug has been actively exploited since at least November 2025 — two days before it was publicly disclosed.
That nine-month gap is the real story here.
What Ray Is
Ray is the framework AI and ML teams use when a single machine isn't enough. You need to distribute a training run across five GPUs, or serve a language model to a hundred concurrent users, or run a batch inference job over a million records — Ray handles the coordination. It's the plumbing under a lot of AI infrastructure you'd recognize.
Anyscale built it and maintains it. AWS SageMaker, Google Vertex AI, and CoreWeave all integrate with Ray. Many teams running their own GPU servers use it directly. If anyone on your team has run distributed AI experiments in the last two years, there's a reasonable chance Ray was involved.
Ray installs with a dashboard — a web UI on port 8265 — and that dashboard, by design, has no authentication. This was a documented, conscious decision: the Ray team considered the dashboard an internal tool, not something you'd expose publicly. That assumption is the root of every problem here.
The Attack
CVE-2025-62593 is a CVSS 9.4 critical remote code execution vulnerability. The attack chain is a DNS rebinding attack combined with a User-Agent header bypass.
You don't need a publicly exposed Ray instance to be at risk. The attack works through a browser.
A developer has Ray running on their laptop or internal network. They visit a website — a malicious page, or just an ad served on a legitimate site — while Ray is up. The attacker-controlled page exploits DNS rebinding to make the browser treat the local Ray dashboard as the same origin as the attacker's server. Ray's only defense against this was checking whether the User-Agent header started with "Mozilla" — which browsers let you modify. The check fails. The attacker now has unauthenticated access to Ray's job submission API, which lets them execute arbitrary code on the machine running Ray.
No VPN exposure. No open port in your firewall. Just a developer with Ray running and an ad network serving malicious content.
ShadowRay 2.0
The campaign that picked this up is called ShadowRay 2.0. It converts infected Ray clusters into self-replicating cryptocurrency mining botnets, specifically targeting machines with NVIDIA GPUs.
AI teams run expensive GPU hardware. Attackers want free GPU compute for crypto mining. Ray clusters are a better target than most corporate endpoints because the machines are more powerful, often left running unattended during training jobs, and the teams running them are focused on AI, not security.
The "self-replicating" part is what makes it a botnet rather than a one-off compromise. Once inside a Ray cluster, the malware scans for other reachable Ray instances on the same network and propagates. Your one infected machine becomes a beachhead.
According to a BitSight report cited in the CISA advisory, threat actors behind the RondoDox DDoS botnet incorporated this exploit into their toolkit before CVE-2025-62593 was ever publicly disclosed — meaning they found it independently, weaponized it, and had been running campaigns for at least two days before the security community even knew the vulnerability existed. That disclosure was November 26, 2025. The campaign has now been running for nine months.
Why You Should Care Even If You're Not Running Ray
Your cloud ML provider might be running Ray. If your team uses any managed AI training or inference platform, there's a real chance Ray is in the underlying stack. You don't control whether those services are patched — but you should be asking. If your vendor is on an affected Ray version and your workloads share infrastructure with other customers, a lateral movement story becomes possible.
Developers run things locally. Most small teams don't have air-gapped dev environments. Someone running a local Ray cluster to test something is browsing the internet on the same machine, same network. The DNS rebinding attack doesn't care about your firewall rules.
This is the third major AI framework RCE in three months. Langflow, CrewAI, now Ray. Open-source AI frameworks get deployed fast, security review comes late, and attackers are finding these before defenders are patching them.
AI infrastructure is a high-value target now in a way it wasn't two years ago. Attacking a small team's servers used to mean getting access to email and files. Today a small team running AI might have GPU infrastructure worth thousands of dollars per hour of compute time. Crypto miners have done the math.
What To Do Right Now
Check whether Ray is running anywhere. Ask your developers. Check your cloud infrastructure for any services using Ray. Run ray status on machines where anyone has done distributed AI work. If you're not sure, look for processes on port 8265.
Update to Ray 2.52.0 or later. This is the patched version. The fix is available on PyPI. If your managed platform is running Ray, open a support ticket asking about their remediation status for CVE-2025-62593.
Don't expose the Ray dashboard publicly. If you need to access the dashboard remotely, put it behind a reverse proxy with authentication. This is true regardless of whether you're patched — unauthenticated dashboards running on internal networks have broader exposure than most teams realize.
Look at your cloud bills. ShadowRay 2.0 compromises show up as unexpected GPU utilization spikes and billing anomalies. If your costs look weird, don't assume it's a billing error.
If you're running GPU infrastructure for AI, treat it like production infrastructure. Security patching cadence, monitoring, access controls. The assumption that "it's just for experiments" is exactly the gap these campaigns exploit.
The Broader Point
The nine months between exploitation and CISA action isn't unusual — it's becoming the norm for AI infrastructure vulnerabilities. The security community is not keeping up with the pace at which AI tooling is being deployed, and attackers know it.
Most of the AI infrastructure being spun up right now — by small teams, NGOs, public sector orgs figuring out how to run their own models, anyone trying to move faster than their cloud budget allows — was built for capability, not security. The people building it are thinking about model performance, not authentication on dashboard endpoints.
That gap is what ShadowRay 2.0 is living in.
At CivSafe, when we help teams set up AI infrastructure, we treat the security configuration as part of the deployment, not an afterthought. If you're running or planning to run local or cloud AI workloads and you're not sure whether your setup would catch something like this, it's worth having that conversation before your GPU bill tells you something's wrong.