Ray CVE-2025-62593 Explained: CISA KEV, August 2026
The Short Answer
On August 17, 2026, CISA added CVE-2025-62593 — a code injection vulnerability in Ray, the open-source distributed compute engine — to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild.
Federal civilian agencies were given until August 20, 2026 to remediate. That is a three-day window, against a typical KEV deadline measured in weeks.
| Field | Value |
|---|---|
| CVE | CVE-2025-62593 |
| Product | Ray (ray-project/ray) |
| Class | Code injection → remote code execution |
| Added to KEV | August 17, 2026 |
| Federal deadline | August 20, 2026 (3 days) |
| Notable vector | DNS rebinding via developer browser |
| Severity reported | Critical (CVSS 9.4 reported) |
Verified August 23, 2026.
Why Ray Specifically Is a Bad Place to Have This Bug
Ray is not a niche library. It is the distributed execution layer beneath a very large share of production ML: training orchestration, hyperparameter search, batch inference, RLHF pipelines, and model serving through Ray Serve. If an organisation trains or serves models at any scale, there is a meaningful chance Ray is in the path.
A Ray head node is also, by construction, one of the most valuable machines in an ML estate. It typically has:
- Cloud credentials with permission to spin up GPU instances — which is both an exfiltration path and a cryptomining jackpot.
- Access to training data, including whatever proprietary corpus the organisation considers its moat.
- Model weights in transit or at rest.
- The ability to execute arbitrary Python across the entire cluster, because that is literally its job.
Code execution on a Ray head node is not a foothold. It is usually the objective.
The DNS Rebinding Angle
The detail that makes this listing unusual is the delivery mechanism reported alongside it: browser-based RCE via DNS rebinding.
The classic threat model for Ray assumes the cluster sits on a trusted internal network, so authentication is optional. Ray’s own documentation is explicit that a dashboard exposed through a reverse proxy must have authentication or network ingress controls applied externally.
DNS rebinding defeats that assumption without touching the perimeter:
- A developer visits a malicious or compromised web page.
- The page’s hostname initially resolves to the attacker’s server, then re-resolves to an internal or loopback address.
- The browser — which is inside the trusted network — now sends requests to the Ray endpoint on the attacker’s behalf.
- If Ray accepts unauthenticated job submission, the attacker submits code.
The attacker never needed network access to your cluster. They needed one engineer to open a tab. This is why “our Ray cluster is not internet-facing” is not a sufficient answer here, and why laptops running local Ray instances are directly in scope.
What to Do, in Order
1. Patch Ray now. Upgrade to a fixed release. This is the only step that actually closes the vulnerability; everything below is defence in depth.
2. Inventory every Ray deployment, including the unofficial ones. Ray arrives as a transitive dependency of many ML frameworks and gets started by scripts nobody registered as infrastructure. Search for listening dashboard and job-submission ports across workstation subnets as well as cluster subnets.
3. Turn on token authentication. Ray supports token auth for the dashboard and job submission; KubeRay v1.5.1 and later can configure it directly, and earlier versions can enable it with a Kubernetes Secret plus the RAY_AUTH_MODE and RAY_AUTH_TOKEN environment variables. If your clusters have been running unauthenticated because “it’s internal,” fix that in the same change window.
4. Bind to loopback and use SSH port forwarding for access. Do not expose the dashboard on a routable interface. Ray’s documented pattern of tunnelling over SSH is both more secure and, in practice, no less convenient.
5. Enforce origin and host checks at the proxy. DNS rebinding is defeated by validating the Host header against an allowlist at whatever reverse proxy fronts the dashboard. Do this even after patching — it kills the whole vector class, not one CVE.
6. Rotate credentials reachable from the head node. If a cluster was exposed for any period, assume the instance role and any mounted secrets are compromised. Rotation is cheap relative to the alternative.
7. Hunt, do not just patch. KEV listing means exploitation was observed. Check for unexpected job submissions, unfamiliar actors, outbound connections from worker nodes, and new GPU instances in the billing console.
The Broader Signal: AI Infrastructure Is Now on the KEV List
The strategic point of this incident exceeds the CVE. CISA placing an AI compute framework in the KEV catalog with a three-day deadline is a category marker.
For roughly two years, security programmes treated “AI security” as a model-behaviour problem — prompt injection, jailbreaks, data leakage through assistants. Those matter. But the ML platform layer is ordinary software with ordinary vulnerability classes, deployed at speed by teams optimising for research velocity, frequently with authentication disabled because it was inconvenient during a proof of concept that quietly became production.
Ray is unlikely to be the last one. The practical response is to bring ML infrastructure inside your normal vulnerability management programme: asset inventory, patch SLAs, authentication by default, and network segmentation — the same controls you already apply to databases and CI runners, applied to the systems that hold your model weights.