CISA Gives Federal Agencies Three Days to Patch Actively Exploited Ray RCE Flaw

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has given federal agencies just three days to patch a critical flaw in Ray, the open-source framework that scales much of the world’s AI and machine-learning workloads, after adding it to the Known Exploited Vulnerabilities (KEV) catalog on August 17, 2026. The bug, CVE-2025-62593 (CVSS 9.4), turns a developer’s own web browser into a path to remote code execution on their machine.

The three-day clock is the part worth pausing on. CISA’s binding operational directive normally gives civilian agencies about two weeks to remediate a KEV entry. Here, as it did with an N-able N-central flaw earlier this month, the agency compressed the window to 72 hours, setting a remediation deadline of August 20, 2026. The Register notes the acceleration is allowed under Binding Operational Directive 26-04, which lets CISA impose a three-day window on vulnerabilities it considers especially risky. When the agency moves this fast, it is telling defenders the exposure is live and the fix is not optional.

What CISA Actually Flagged

CVE-2025-62593 is a browser-based remote code execution flaw in every version of Ray before 2.52.0. Ray is a Python-native distributed computing framework, started at UC Berkeley and now managed by the Linux Foundation’s PyTorch Foundation, that lets developers push machine-learning jobs from a laptop to a cluster with minimal code changes. That reach is the reason this matters: The Register reports Ray is used and supported by Amazon, Apple, and OpenAI, and per Anyscale’s figures from October 2025 the project had passed 237 million total downloads at roughly 7 million per week. The GitHub repository carries more than 43,500 stars.

What CISA did not do is explain the exploitation. The agency published no technical detail on how the flaw is being used in the wild, and marked the catalog’s “known to be used in ransomware campaigns” field as unknown. The urgency, then, has to be read from the vulnerability itself and from where it has already surfaced.

How a Browser Becomes the Weapon

The flaw is a defeated defense, not a missing one. Ray tried to block browser-originated requests by checking whether the incoming User-Agent header started with “Mozilla.” That check is trivially defeated in two specific browsers: Firefox and Safari both let a script using the Fetch API rewrite that header. Combine the bypass with a DNS rebinding attack against the browser, and a malicious page or ad can reach the Ray service running on the developer’s own loopback address, where sensitive endpoints such as /api/jobs and /api/job_agent/jobs/ require no authentication at all.

The Ray maintainers were blunt about the consequence in their advisory: “If they fall victim to a phishing attack, or are served a malicious ad, they can be exploited, and arbitrary shell code can be executed on their developer machine.” The same advisory credits Oligo researcher Avi Lumelsky with the fetch bypass and Jonathan Leitschuh with the DNS rebinding technique.

Figure: CVE-2025-62593 turns a browser’s own header-rewriting ability into code execution on a developer’s machine, then into a foothold on the wider network.

Who Is Actually Exposed

The primary victims are developers, not production clusters. The maintainers stress the flaw “impacts developers running development/testing environments with Ray,” because the attack needs a browser and a local Ray service on the same machine. That framing narrows the blast radius, but it does not shrink it to nothing. Ray’s security model has long assumed clusters run inside a trusted, isolated network, which is exactly why its critical endpoints ship without authentication.

The more serious twist is lateral. The maintainers warn the technique “can also be leveraged to attack network-adjacent instances of Ray by leveraging the browser as a confused deputy intermediary.” In plain terms, an attacker who compromises one developer’s browser can use it to reach Ray services elsewhere on the corporate network that were never meant to face the internet. A single malvertising impression becomes a way in.

What Is Confirmed, and What Isn’t

Two things are firmly established. The flaw was disclosed on November 26, 2025, and it has a history of abuse. Per The Hacker News, a BitSight report from March 2026 found the operators of the RondoDox DDoS botnet had folded the vulnerability into their toolkit two days before public disclosure, working from an available proof-of-concept. Oligo has separately tracked a campaign it calls ShadowRay 2.0 that hijacks unpatched Ray clusters with NVIDIA GPUs into self-replicating cryptocurrency miners. This is not the first time Ray has drawn this kind of attention, and CISA has repeatedly moved AI and developer tooling into KEV, from Langflow to N-central and Tomcat.

Several things are not confirmed, and it is worth labeling them. CISA has named no specific victims of CVE-2025-62593 and shared no detail on the exploitation it observed. There is no confirmation of impact on Anyscale’s managed Ray Cloud tenants; the reporting concerns self-hosted clusters and developer machines. And the ransomware association remains an open question, marked unknown in the catalog rather than confirmed either way. Treat those gaps as gaps, not as reassurance.

What Ray Operators Should Do Now

The defender playbook here is short and concrete.

• Patch to Ray 2.52.0 immediately. This is the fixed release, and it is the only action that closes the flaw outright. Federal civilian agencies have until August 20, 2026; everyone else should treat that same date as the sane ceiling, not a suggestion.
• Get the Ray Dashboard and API off the internet. Ray’s endpoints assume network isolation and ship without authentication, so a dashboard or /api/jobs endpoint reachable from the public internet is a standing invitation. Confirm no Ray port is exposed, and bind services to a controlled network segment.
• Turn on the new token authentication, but do not lean on it. Version 2.52.0 adds optional token-based authentication, and it is disabled by default. Enable it as defense in depth, while keeping cluster isolation as the primary control the project still recommends.
• Audit developer workstations for the lure path. Because the exploit rides in through phishing and malvertising, review endpoint and browser protections on machines that run Ray locally, and remind developers not to browse untrusted sites or click ad links from a session where a Ray service is live on localhost.

My read (assessment, not reported fact): the three-day deadline is doing more work as a signal than the sparse public detail suggests. CISA gave no exploitation specifics and left the ransomware field blank, yet it still reached for the fastest window its directives allow. Given a public proof-of-concept, a botnet that weaponized this before disclosure, and Ray’s footprint across the biggest AI shops, the compressed clock reads as a bet that attackers are already ahead of the patch curve on developer machines. The uncomfortable part is that the exposed asset is a laptop with a browser open, which is far harder to inventory than a server.

Primary documents

• Ray security advisory GHSA-q279-jhrf-cc6v (CVE-2025-62593)
• CISA Known Exploited Vulnerabilities catalog
• The Hacker News: CISA flags actively exploited Ray flaw
• The Register: CISA gives feds 3 days to fix the Ray RCE bug