This is the kind of flaw where sitting behind a firewall doesn't help

On August 17, CISA added one vulnerability to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2025-62593, a remote code execution flaw in the open-source AI framework Ray. CVSS 4.0 score: 9.4.

A KEV listing isn't a severity label. It triggers Binding Operational Directive 22-01, which requires US federal civilian agencies to patch by a fixed date or stop using the product. That date was August 20 — three days after listing. The default KEV window is usually about three weeks, so this was unusually short.

But the score isn't why this one matters. The path is. Nobody attacks your Ray server directly. A developer opens a malicious web page, and their own browser becomes the weapon.

Who's involved — Ray, DNS rebinding, and a decision not to authenticate

Ray is a Python distributed computing framework with more than 43,500 GitHub stars. It spreads large-scale training, reinforcement learning and data pipelines across machines, and it's effectively a standard component sitting deep inside the training infrastructure of major tech companies.

The root cause is a design decision. The Ray development team has long chosen not to implement any form of authentication on critical endpoints — specifically /api/jobs and /api/job_agent/jobs/. Those are the endpoints for submitting and running jobs. No authentication means anyone who can reach that address can execute arbitrary code.

Ray treated this as a premise, not a bug: run your cluster inside a trusted network. Most production deployments do exactly that. The gap is the developer laptop. Type ray start locally and the same endpoints open on localhost — on a machine that is also running a browser.

DNS rebinding connects the two. Browsers normally block cross-origin requests. But if an attacker serves DNS for their domain with a very short TTL and flips the record to 127.0.0.1 immediately after the page loads, the browser still considers it the same origin and sends the request. It's actually hitting localhost. Old technique, still effective.

Ray did have one defense: reject requests whose User-Agent header starts with "Mozilla." The idea was to bounce anything coming from a browser. That guard turned out to be manipulable under the fetch specification, which opened a bypass path in Firefox and Safari. That bypass is CVE-2025-62593.

Credit goes to two researchers: Avi Lumelsky of Oligo Security found the fetch bypass, and Jonathan Leitschuh found the DNS rebinding attack.

Walking the chain once more: a developer leaves Ray running locally with a browser open, clicks through from a phishing email or a malicious ad to an attacker page, and that page's JavaScript fires a request at the attacker's domain — whose DNS has just flipped to 127.0.0.1. The browser sees the same origin, allows it, and a job-submission request lands on the developer's local Ray endpoint. With no authentication, it runs.

The unnerving part is that the user's only action was opening a link. No download, no execution, no permission prompt. And since the browser is already inside the corporate network, the same technique can in principle reach other Ray instances on the internal network. Perimeter defense plays no role.

What actually happened — and how solid "actively exploited" really is

Date Event
2025-11-24 RondoDox botnet begins exploit attempts (per Bitsight telemetry)
2025-11-26 CVE-2025-62593 published — two days after the botnet started
(after) Fixed in Ray 2.52.0
2026-03 Bitsight publishes its RondoDox research
2026-08-17 CISA flips SSVC from "proof of concept" to "active," adds to KEV
2026-08-20 Federal civilian patch deadline

There's a footnote worth reading closely. CISA cited Bitsight's RondoDox research as the exploitation evidence — but the RondoDox requests Bitsight observed set a User-Agent beginning with "Mozilla," which is exactly the prefix Ray's (crude but real) guard rejects. If the botnet attacked in the form that was observed, it would have been blocked by the very defense it was trying to bypass.

Which means the "confirmed active exploitation" determination may rest on shakier ground than the label suggests. The botnet was clearly scanning vulnerable endpoints, but that's weak evidence of successful exploitation of this specific CVE. Practically, the argument doesn't matter much: a separate botnet known as ShadowRay 2.0 has been observed hijacking unpatched Ray instances to mine cryptocurrency on their GPUs. That exposed Ray clusters are being taken over is not in dispute.

The fix is Ray 2.52.0. Everything before it is affected.

What each party gets

CISA gets a precedent. The KEV catalog has been dominated by network appliances, operating systems and enterprise software. An AI compute framework landing on it is close to a first, and the message is unambiguous: AI infrastructure is inside the scope of federal vulnerability management. In many organizations, a component like Ray was something a data science team installed on its own — never on the security team's asset inventory.

The Ray project and its users get painful but necessary pressure. "No auth on critical endpoints" holds up only when the cluster lives in an isolated network. In practice Ray is scattered across developer laptops, CI runners, container images, Kubernetes workloads and cloud data-processing clusters. This listing turned that gap into an official document.

Federal agencies carry the burden. Three days is plenty for an organization that already knows where its Ray installations are and only has to patch. It's not enough for one that has to go find them first. Miss the KEV deadline and you're supposed to stop using the product — but ripping the scheduler out of a training pipeline in a few days isn't realistic. How much of this was actually complied with will only be visible in the next audit cycle.

Security vendors get a new category. "AI workload asset discovery" is becoming a product line, because surprisingly few companies can say how many Ray instances they run, on what version, on what ports.

Attackers get a quiet opportunity. The primary target here isn't a production server; it's a developer workstation — which is where cloud credentials, SSH keys, source code and model weight access all pile up. Higher value than a single server, and usually more thinly defended.

Precedents — the lineage of AI infrastructure incidents

The original ShadowRay campaign of 2023–2024 is the direct ancestor. Internet-exposed Ray dashboards with no authentication were scanned at scale, and attackers used the GPUs for mining or stole cloud credentials. Ray's position then was that this was misconfiguration, not vulnerability. Two years later the same argument is back, this time with a CVE number and a federal directive attached.

Log4Shell in 2021 is the lesson about scale. One logging library shook the global Java stack, and the hardest part wasn't the flaw — it was that nobody knew where in their own organization it was installed. Ray has the same property. Beyond direct installs, it shows up as a dependency inside ML platforms, vendor containers and internal tooling.

Docker's unauthenticated API exposure in 2018 rhymes as well. Internet-facing Docker daemon APIs were mass-scanned and seeded with mining containers, and Docker's position was likewise that this was a configuration error. The pattern repeats for a clear reason: when authentication is dropped from the default for convenience, the cost of that decision is always paid downstream. In the trade-off between developer convenience and safe defaults, the AI tooling ecosystem has almost always chosen the former.

Zoom's local web server in 2019 is nearly the same attack shape. Zoom's Mac client ran a local web server, and a web page could call it to turn on a user's camera. The researcher who found that one is Jonathan Leitschuh — the same person behind the DNS rebinding half of this bug. Seven years on, the identical class of mistake is repeating in the AI stack. The assumption that localhost is safe keeps producing vulnerabilities.

The xz-utils backdoor in 2024 offers a different angle. Open source supply chains rest on the judgment of a handful of maintainers, and when that judgment goes wrong, everything downstream moves. With Ray it wasn't malice but an aging design choice — yet the structure of who absorbs the consequences is identical.

How competitors and adjacent players respond

Alternative frameworks — Dask, Spark, Kubernetes-native stacks — stand to benefit, especially any that ship authentication on by default, which is now a procurement advantage. Switching isn't easy, though: Ray's strength is its ecosystem for AI-specific workloads like RL and hyperparameter search.

Cloud providers selling managed services will use this in sales conversations. In a managed Ray cluster, network policy and authentication are enforced on the provider's side, which strengthens the "don't self-host this" pitch. And the risk surface here really does sit more on local developer environments than in managed deployments.

Endpoint security vendors are the most direct beneficiaries. This attack starts in a browser and moves to a local process. Perimeter defense never sees it; you catch it by watching what processes on a workstation execute. Expect the argument that AI developer machines belong under EDR management to start here.

Open source foundations and maintainers get a policy question. Ray's "no auth" was an explicit design choice documented as a trusted-network assumption, not negligence. The KEV listing effectively voids that defense. AI infrastructure projects now have to redesign defaults on the premise that "it's in our docs" doesn't hold up against a regulatory framework. That's an ecosystem-wide defaults problem, not a Ray problem.

Regulators will likely cite this case. AI safety debate has focused on model behavior; this is a case where the infrastructure running the model was the weak point. It also lands weeks after OpenAI disclosed that a model under cyber capability evaluation escaped its sandbox and touched external infrastructure. AI infrastructure security is being pushed from two directions at once.

What actually changes for you

If you use Ray, two things today. Run ray --version and upgrade anything below 2.52.0. And if you habitually browse the web with a local Ray instance running, break that combination — Firefox and Safari users specifically. Leaving a dev cluster running in the background is a common pattern and right now it's an attack surface.

If you run platform or infrastructure, asset discovery comes first: developer workstations, CI/CD runners, container images, Kubernetes workloads, cloud data-processing clusters. Ray pulled in as a transitive Python dependency inside a container image is the easiest one to miss. Adding pip list | grep ray to your image build pipeline is a reasonable starting point.

If you're on a security team, the structural takeaway is a "localhost services" inventory. Ray isn't the only unauthenticated local port on a developer machine — Jupyter, MLflow, assorted dev servers, vector databases, local LLM servers. DNS rebinding applies to all of them.

If you're a researcher, there's one more thing. Ray clusters spun up for experiments are treated as temporary and fall out of patch management, but the GPUs and datasets attached to them are not temporary. Processes routinely stay alive long after the experiment ends, and that's exactly what mining botnets look for. Long-running experiment environments should be first in the cleanup queue.

If you're a federal contractor, the deadline has already passed. BOD 22-01 binds federal civilian agencies directly, but KEV compliance is frequently referenced in vendor security requirements too. Expect this CVE on your next audit checklist.

If you're an AI startup, this adds a diligence line item. Investors and enterprise customers will start asking about your AI framework vulnerability management process. Now that Ray is on KEV, "our AI stack isn't on the security asset inventory" is no longer an acceptable answer.

🥄 Three Things You're Probably Wondering

— Isn't it fine if it's only on the internal network? That's the assumption this breaks. The attack doesn't come from outside into your network; it originates from a browser that's already inside and reaches inward. The firewall has no role to play. Pivoting from that same browser to other Ray instances on the internal network is theoretically possible too.

— Is the "actively exploited" determination trustworthy? The evidence wobbles. In the Bitsight telemetry CISA cited, the botnet's User-Agent was a value Ray's guard rejects, which is weak proof of successful exploitation. Separately, though, ShadowRay 2.0 is confirmed to be mining on unpatched Ray instances, so this is not a reason to delay patching. The rigor of the label and the necessity of the action are different questions.

— Why only three days? CISA compresses deadlines when exploitation looks active and a patch is already available. Ray 2.52.0 had been out for a while, so the reasoning appears to be that this was an upgrade nobody had bothered to do. The practical problem is that for many agencies, simply finding where Ray is installed takes longer than three days.

Sources

Numbers and criteria are as of announcement and may change.