Ray CVE-2025-62593: CISA Flags Exploited RCE Flaw

A critical flaw in one of the most widely used frameworks for scaling AI workloads is now confirmed to be under active attack. On August 17, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-62593, a remote code execution vulnerability in the open-source Ray framework, to its Known Exploited Vulnerabilities (KEV) catalog, and gave federal agencies just three days — until August 20, 2026 — to patch or stop using affected systems.

The flaw is unusual: it lets an attacker execute code on a developer’s machine through an ordinary web browser, with no direct network access to the Ray cluster required. That makes it both easier to exploit than a typical server bug and harder for defenders to reason about.

What Ray is and why it matters

Ray is an open-source, Python-native distributed computing framework used to scale AI and machine-learning workloads across clusters of machines. It is a foundational piece of infrastructure for training and serving large models, and it commonly runs on clusters packed with Nvidia GPUs — precisely the high-value compute that attackers most want to hijack. For background on why that hardware is so prized, see our explainer on what a GPU is.

Ray exposes a dashboard and job-submission API that operators use to monitor jobs and dispatch work. Those interfaces are the attack surface at the center of this vulnerability — and of the broader wave of Ray-targeting campaigns over the past year.

How CVE-2025-62593 works

CVE-2025-62593 carries a CVSS score of 9.4, in the critical range. It stems from a weak defense in Ray’s dashboard: to block malicious cross-origin requests from a browser, Ray checked whether the incoming HTTP User-Agent header started with “Mozilla.” The assumption was that a request bearing a browser’s user-agent must be a harmless browser navigation, not a scripted attack.

That assumption is false. Browsers let pages influence request headers, and the check does nothing to stop a crafted page from reaching the dashboard. Combined with a DNS rebinding attack, the weakness becomes a full remote code execution primitive.

DNS rebinding works by abusing the gap between a browser’s same-origin protections and the actual network. An attacker lures a developer to a malicious website — or serves a malicious advertisement — while that developer is running Ray locally or on a reachable host. The attacker’s domain first resolves normally, then rebinds to a local or internal address where the Ray dashboard lives. The victim’s browser, believing it is still talking to the attacker’s origin, sends requests straight to the Ray API on the developer’s own network. From there, submitting a job means running arbitrary code.

The upshot: simply visiting a malicious page while Ray is running can be enough to compromise the machine. No stolen credentials, no exposed public port, no phishing attachment — just a browser tab.

The patch

Ray version 2.52.0 fixes the issue. The update hardens the dashboard against browser-based cross-origin requests and, notably, adds an authentication feature for the dashboard and API — though that authentication is disabled by default, so operators must turn it on to gain its protection. Any deployment running a Ray version before 2.52.0 should be considered vulnerable.

Because Ray clusters are often stood up quickly for experimentation and left running, and because many were deployed long before this fix existed, the population of exposed, unpatched instances is large. That is a recurring theme with infrastructure software that started life as an internal tool: convenient defaults age into security liabilities. It echoes the pattern we saw with the N-able N-central auth-bypass flaw and the steady stream of zero-day vulnerabilities landing in enterprise platforms.

Active exploitation: RondoDox and ShadowRay 2.0

CISA does not add a bug to the KEV catalog on theory. This one has a documented exploitation history.

The vulnerability was publicly disclosed on November 26, 2025, and a proof-of-concept exploit was available. According to a BitSight report from March 2026, the operators of the RondoDox DDoS botnet had already folded the flaw into their toolkit two days before the public disclosure — a reminder that the window between a bug becoming known to attackers and becoming known to defenders is often negative. For context on how these networks are weaponized, see our primer on DDoS attacks.

Separately, security firm Oligo documented a campaign it dubbed ShadowRay 2.0, in which attackers turn unpatched Ray clusters — including those loaded with Nvidia GPUs — into a self-replicating cryptocurrency-mining botnet. Compromised clusters mine cryptocurrency using their powerful accelerators and, in some observed cases, are also enlisted for denial-of-service attacks, making the operation a multi-purpose botnet rather than pure cryptojacking. ShadowRay 2.0 primarily leverages a separate, long-standing missing-authentication issue in Ray’s job API, but the campaign underscores the same core exposure: internet-reachable Ray dashboards with no authentication in front of them.

The combination — a browser-triggerable RCE, an active DDoS botnet, and a GPU-hijacking cryptomining campaign — is what pushed CVE-2025-62593 onto the KEV list and triggered the compressed federal deadline.

What defenders should do

For teams running Ray, the immediate actions are direct:

• Upgrade to Ray 2.52.0 or later without waiting for a maintenance window; the browser-based vector does not require the cluster to be publicly exposed.
• Enable the dashboard/API authentication added in 2.52.0. It is off by default, so patching alone leaves that hardening unused.
• Do not expose the Ray dashboard or job-submission API to untrusted networks, and place them behind network controls even for internal use.
• Inventory shadow deployments. Ad-hoc clusters spun up by data scientists are exactly the instances most likely to be forgotten and unpatched.

What it means

The Ray disclosure is a clean example of a trend that will define AI-infrastructure security for the next several years: the tools built to make machine learning fast and convenient were not built to be exposed to the open internet, and attackers have noticed.

Who is exposed. Any organization running Ray for training or inference — which is a large and growing set of AI teams — and especially those with GPU-dense clusters, which are the most attractive targets for cryptomining. The browser-based nature of CVE-2025-62593 widens the blast radius beyond servers to the workstations of individual developers, a population that rarely thinks of itself as running exploitable network services.

Why the browser vector matters. DNS rebinding turns a developer’s own machine into the pivot point, sidestepping firewalls and the assumption that “internal only” equals “safe.” Defenders accustomed to protecting the perimeter have to reckon with an attack that arrives through a tab. The lesson generalizes: any local developer service that trusts the browser’s origin model without real authentication is a candidate for the same class of attack.

The bigger pattern. GPUs are now valuable enough that hijacking them for cryptomining is a business, and AI frameworks are becoming a preferred entry point. Expect more KEV additions targeting the ML tooling stack — orchestrators, notebook servers, model registries, and job schedulers — as attackers follow the compute. The defensive takeaway is uncomfortable but simple: treat AI infrastructure as production infrastructure, with authentication on by default, network segmentation, and patch discipline, rather than as disposable lab gear.

The things to watch next: how quickly the exposed Ray population shrinks now that CISA has forced federal attention onto it; whether ShadowRay-style campaigns expand to other AI frameworks with similar default-open designs; and whether maintainers across the ecosystem move to make authentication the default rather than an opt-in — the single change that would blunt this entire attack class.