CVE-2025-62593: CISA Adds the Ray AI Compute Flaw to KEV and Gives Federal Agencies Three Days

On August 17, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added a single vulnerability to its Known Exploited Vulnerabilities catalog: CVE-2025-62593, a code injection flaw in Ray, the open-source distributed compute engine that underpins a very large share of production machine learning training and inference infrastructure. The remediation due date for Federal Civilian Executive Branch agencies was August 20, 2026 — three days. The compressed timeline reflects BOD 26-04, "Prioritizing Security Updates Based on Risk," which replaced the flat fourteen-day KEV remediation clock with a risk-tiered model. Vulnerabilities on publicly exposed assets that grant total control of the asset post-exploitation get the shortest deadlines. Ray qualifies on both counts.

This article walks through what CVE-2025-62593 is, why CISA moved on it so quickly, how the attack works at a technical level, and what platform, security, and AI infrastructure teams should do in response.

What CVE-2025-62593 actually is

CVE-2025-62593 affects Ray versions before 2.52.0 and carries a CVSS score of 9.4. It is a failure of protection against browser-based attacks on the Ray dashboard and API. The mechanism is worth reading carefully, because it is a small architectural mistake with an unusually large blast radius.

Ray ships with a dashboard and a set of HTTP API endpoints that are intended to be run on a developer workstation, a research cluster, or an internal production environment. The dashboard's purpose is to let users submit jobs, inspect logs, and manage the cluster. Two of those endpoints — `/api/jobs` and `/api/job_agent/jobs/` — accept job submissions and are the primary mechanism through which workloads enter the cluster. In the vulnerable versions of Ray, those endpoints do not require authentication.

The dashboard did have a User-Agent-based check intended to prevent browsers from submitting state-changing requests. The check looked at the User-Agent header of an incoming HTTP request and rejected requests that looked like they originated from a browser. The check was incomplete. An attacker who could craft an HTTP request with a non-browser User-Agent header could submit jobs directly to those endpoints.

That architectural decision — critical job-submission endpoints reachable without authentication, with a User-Agent check as the only protection — is the surface that CVE-2025-62593 exploits. The attacker combines the missing authentication with a DNS rebinding attack that allows a malicious webpage running in the victim's browser to reach the Ray service running on the victim's localhost.

How the attack works end to end

The end-to-end attack requires four conditions, each of which is realistic in a development environment:

1. The victim has a Ray dashboard or API running on their workstation, accessible at `localhost` or on the local network. 2. The victim visits a malicious webpage in Mozilla Firefox or Apple Safari, or has a malicious advertisement served to them on a legitimate site. 3. The malicious page initiates a DNS rebinding attack that resolves a DNS name the attacker controls to `127.0.0.1` after an initial resolution to the attacker's server. 4. The malicious page submits a job to the Ray endpoint at the rebinded address.

The DNS rebinding step is the key trick. A typical browser same-origin policy treats two URLs as same-origin if they have the same scheme, host, and port. By controlling DNS resolution for a domain the attacker owns, the attacker can make the browser initially load content from a server the attacker controls, then rebind the domain to `127.0.0.1` for subsequent requests. The browser continues to treat requests to the domain as same-origin — because the host portion of the URL is the same string — while the requests are actually being sent to the Ray service on the victim's own machine.

The User-Agent check on the Ray side was intended to prevent this kind of cross-origin attack. The check is bypassable because the attacker can either craft a fetch request with a custom User-Agent string or use a browser feature that allows non-browser User-Agent headers. The result is that a malicious webpage can submit an arbitrary job to a Ray cluster running on the same machine as the browser, executing attacker-controlled code at the privilege of the Ray process.

Disclosure timeline and credit

The vulnerability has a layered credit history. Ray maintainers published an advisory in November 2025 that described the design issue and credited researchers for related work. The specific attack chain that produces browser-driven RCE via DNS rebinding was developed and disclosed by Oligo Security researcher Avi Lumelsky, with the DNS rebinding technique credit going to independent researcher Jonathan Leitschuh. The patch was released in Ray 2.52.0, with a follow-up 2.52.1 recommended for production deployments.

The CVE record and the KEV addition came several months later, on August 17, 2026, after CISA confirmed active exploitation. The choice to add this CVE rather than a different Ray CVE reflects the operational risk profile: code injection, browser-driven, no authentication required on critical endpoints, exploitable against developer workstations, with a published PoC.

Active exploitation in the wild

The KEV addition is not a precaution. CISA added the CVE after confirming active exploitation. BitSight reported in March 2026 that operators of the RondoDox botnet had incorporated CVE-2025-62593 into their toolkit before public disclosure, with a proof-of-concept exploit available to speed integration. Oligo separately reported a campaign dubbed ShadowRay 2.0 that targets unpatched Ray clusters equipped with NVIDIA GPUs, with the goal of converting infected systems into self-replicating cryptocurrency mining botnets.

The ShadowRay 2.0 campaign is particularly concerning because Ray is the de facto standard for distributed GPU workloads in AI/ML, and an infected Ray cluster has access to both significant compute and to the cloud credentials that the cluster uses to pull data and submit training jobs. A successful compromise can result in theft of training data, theft of model artifacts, theft of source code, abuse of GPU compute for cryptomining, and pivot to the cloud environment the cluster is integrated with.

For organizations that run Ray in production AI/ML environments, the threat model is now "expect compromise" for any Ray deployment that has not been patched to 2.52.0 or later, that has not had token authentication enabled, and that has not had network exposure reduced.

The federal response and BOD 26-04

The three day federal remediation deadline reflects the BOD 26-04 risk-tiered model, which replaced the flat fourteen-day KEV remediation clock. The directive assigns the shortest deadlines to vulnerabilities that grant total control of the asset post-exploitation and that affect publicly exposed assets. Ray qualifies on both counts: a successful exploit gives the attacker arbitrary code execution as the Ray process, and many Ray deployments are intended to be reachable from developer workstations, which makes the surface effectively public from the perspective of any user with local network access.

The compressed timeline is not arbitrary. CISA's analysis, which is documented in the KEV entry and in supporting guidance, concludes that the operational risk of leaving CVE-2025-62593 unpatched in a federal environment is high enough to justify a three day window. Federal agencies that did not patch by August 20, 2026 are now in violation of BOD 26-04 and must report their status to CISA.

For non-federal organizations, the compressed federal timeline is a useful signal. If CISA believes three days is the appropriate window for the federal civilian executive branch, that is strong evidence that any organization running Ray should treat the patch as urgent and should not wait for the next regular maintenance window.

Mitigation and remediation

The mitigation playbook for CVE-2025-62593 is straightforward, but the operational discipline required is not.

1. **Upgrade Ray to 2.52.0 or later, preferably 2.52.1.** This is the primary mitigation. The upgrade must be applied to every Ray deployment, including developer workstations, research clusters, internal production environments, and any external-facing deployment. 2. **Enable token authentication on every Ray cluster.** Token authentication was introduced in Ray 2.52.0 and is the recommended baseline for any deployment that does not sit behind a strictly isolated network boundary. The Ray documentation describes the steps for generating a long-lived token and configuring the cluster to require it. 3. **Restrict network access to Ray management interfaces.** Ray dashboard and API endpoints should not be exposed to the public internet. They should not be exposed to a corporate network beyond the set of users who genuinely need access. Where the dashboard must be reachable, it should be behind a VPN, a zero-trust network access broker, or an authenticated reverse proxy. 4. **Investigate affected systems for signs of compromise.** Any Ray deployment that was reachable between the November 2025 advisory publication and the moment of patching should be treated as potentially compromised. Specific things to look for include unexpected jobs in the job history, unexpected Python or shell processes spawned by the Ray process, outbound connections to known cryptocurrency mining pool addresses, unexpected cloud API calls from the cluster, and any modifications to the Ray source code, configuration, or installed Python packages. 5. **Review the supply chain for shadow Ray deployments.** Ray is easy to install via `pip install ray` and is frequently added to machine learning environments by individual developers without a formal review. A practical first step is to query your endpoint management or EDR tool for installations of the `ray` Python package and Ray dashboard processes.

Detection engineering

The detection signals for an active CVE-2025-62593 exploit are reasonably distinctive, because the attack involves a browser-driven submission to a local API. Specific things to hunt for:

- Network connections from a browser process to a local port that is running Ray (default ports are 8265 for the dashboard, 10001 for the client server, and 8076 for the agent). - Submission of jobs to a Ray cluster from a User-Agent string that does not match the expected patterns of common Ray client libraries. - Ray job history entries with names, command lines, or working directories that do not match the legitimate workload of the cluster owner. - Ray cluster processes that spawn unexpected child processes, particularly Python or shell subprocesses. - Outbound connections from the Ray cluster to cryptocurrency mining pool addresses or to domains that are not part of the legitimate workload.

For organizations with EDR coverage on developer workstations, a high-fidelity signal is a Ray process on a workstation that spawns a child process that makes outbound network connections to a non-allowlisted destination. For organizations with cloud-native detection tooling, the equivalent signal is a Ray cluster running on a cloud VM that makes IAM API calls that are not part of the expected workload.

A practical immediate detection is to alert on any Ray deployment that is listening on a publicly reachable network interface. The default Ray configuration listens on `0.0.0.0`, which means that the dashboard is reachable from any network that the host is on. For workstations on a corporate network, that means the dashboard is reachable from any other workstation on the same network segment. Detection of a Ray dashboard listening on a public interface is a strong indicator that the deployment is exposed beyond what is operationally necessary.

The broader lesson: localhost is not a security boundary

CVE-2025-62593 is one of a class of vulnerabilities in which the trust placed in `localhost` as a security boundary proves to be unwarranted. The Ray dashboard is intended to be reached from the same machine that runs it. The assumption is that the only person who can reach `localhost:8265` is the developer sitting at the keyboard. The DNS rebinding attack breaks that assumption by allowing a remote attacker to make HTTP requests that originate from the developer's browser but are directed at `localhost`.

The pattern shows up repeatedly in developer tools: dashboards, IDE plugins, language servers, ML frameworks, and infrastructure CLIs all run on localhost and all assume that the only attacker model is "someone sitting at the keyboard." The reality in 2026 is that the browser is the new attack surface for these tools, and any tool that runs an unauthenticated HTTP service on localhost is a candidate for the same class of bug.

The architectural lesson is that developer tools should require authentication by default, should bind to specific host addresses rather than `0.0.0.0`, should require explicit user consent before binding to a network-accessible interface, and should warn loudly when a default configuration is changed in a way that exposes the service beyond localhost. The Ray maintainers have made progress on these defaults in the 2.52.x line; the broader developer tools ecosystem has a long way to go.

What to do in the next 48 hours

For any organization running Ray, the next 48 hours are about closing the gap between the patch availability and the operational reality. The recommended sequence:

1. Inventory every Ray deployment. Use endpoint management, EDR, or a manual query to find every host that has Ray installed, every cluster that is running, and every dashboard that is reachable. 2. Patch every deployment to 2.52.0 or later. Where patching is not immediately possible, disable the Ray dashboard, kill the dashboard process, and block the dashboard ports at the network layer. 3. Enable token authentication on every cluster. This is not optional for any deployment that is reachable beyond a strictly isolated network. 4. Audit the last 90 days of activity on every Ray cluster. Look for unexpected jobs, unexpected processes, unexpected outbound connections, and unexpected cloud API calls. 5. Communicate the remediation status to executive leadership. The board-level question is whether the organization has any Ray deployment that has not been patched. If the answer is yes, the organization has accepted the operational risk of leaving a KEV-listed, actively exploited vulnerability unaddressed.

Closing thoughts

CVE-2025-62593 is the kind of vulnerability that the security community has been warning about for a decade: critical infrastructure, missing authentication, browser-accessible, exploit code public, active exploitation confirmed. The fact that it took nine months from the original November 2025 advisory to the KEV addition is itself a useful data point about how slow the security ecosystem can be to react to vulnerabilities in developer tools.

The compressed BOD 26-04 timeline is the right signal. Three days is the appropriate window for a vulnerability of this profile. Organizations that take longer than that to patch should treat the gap as an executive-level operational risk, not as an IT backlog item.

The verified sources for the technical claims in this article include the CISA KEV entry for CVE-2025-62593 dated August 17, 2026, the Resecurity technical write-up of the DNS rebinding attack chain, the BitSight March 2026 report on RondoDox incorporation of the exploit, the Hacker News coverage by Swati Khandelwal, the Compliance Hub Wiki analysis of the BOD 26-04 timeline, and the Oligo Security research notes that document the ShadowRay 2.0 campaign.