Three Days to Patch: CISA Orders Emergency Fix for Actively Exploited Ray AI Framework Flaw

The US Cybersecurity and Infrastructure Security Agency (CISA) has invoked an emergency patching directive against a vulnerability in one of the most widely deployed pieces of AI infrastructure in the world. On August 17, the agency added CVE-2025-62593 — a critical remote code execution flaw in Ray, the open-source distributed computing framework that powers machine learning workloads at Amazon, Apple, and OpenAI — to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation in the wild. Federal civilian agencies have until August 20 to remediate it. That is a three-day window, not the standard fourteen.

What is Ray, and why does this matter?

Ray is a Python-native framework for scaling AI and machine learning workloads from a laptop to a cluster with minimal code changes. Born at UC Berkeley, commercialized through the startup Anyscale, and now stewarded by the Linux Foundation’s PyTorch Foundation, Ray has become quiet infrastructure for the modern AI stack. Its GitHub repository has amassed more than 43,500 stars and over 7,900 forks. According to Anyscale’s figures from October 2025, the package had surpassed 237 million total downloads and was pulling 7 million downloads per week — nearly tenfold year-on-year growth. Product analysis site NextSprints estimates Ray has around 1 million monthly active users and is used by roughly 60 percent of Fortune 500 companies.

In other words: this is not a niche library. It is the compute substrate under a meaningful slice of the world’s ML training and inference pipelines, and a large fraction of those deployments are running versions older than 2.52.0.

The vulnerability: a browser, a header, and a missing lock

CVE-2025-62593 carries a CVSS v4 score of 9.4 — critical territory. The bug, first disclosed on November 26, 2025, is a code injection flaw in Ray’s HTTP API endpoints, most notably /api/jobs and /api/job_agent/jobs/. Those endpoints have a notorious history: Ray’s security model long assumed clusters would live inside a trusted, isolated network, so the framework shipped with no authentication on critical APIs, delegating access control to surrounding infrastructure.

The 2025 flaw compounds that design decision with a subtle browser trick. Vulnerable Ray versions try to block browser-driven requests by checking whether the User-Agent header begins with “Mozilla.” But Firefox and Safari — unlike Chrome — allow scripts using the Fetch API to modify that header, which is normally a forbidden header name. Strip the “Mozilla” prefix, and Ray’s browser defense evaporates.

Chain that with a DNS rebinding attack, and the result is ugly:

1. A developer running Ray locally visits a malicious website, or is served a malicious advertisement, in Firefox or Safari.
2. The attacker’s page uses DNS rebinding to make the browser’s requests resolve to the local Ray service — bypassing the same-origin policy.
3. With the modified User-Agent, the request sails through, and arbitrary shell code executes on the developer’s machine.

Worse, the attack doesn’t stop at the endpoint. Ray’s maintainers warn that the browser can act as a “confused deputy” intermediary, letting an attacker pivot from a phished laptop to network-adjacent Ray instances running inside a private corporate network — the exact clusters doing production ML work. Chrome users are substantially better off here, since Chrome does not permit Fetch-based User-Agent modification.

The flaw was fixed in Ray 2.52.0, which also introduced optional token-based authentication for the first time — though it remains disabled by default, and the project still recommends network isolation over relying on authentication. Credits for the discovery go to Oligo security researcher Avi Lumelsky, who found the Fetch header bypass, and Jonathan Leitschuh, who developed the DNS rebinding technique.

Who is actually exploiting it?

CISA has not described the in-the-wild exploitation in detail, and the catalog’s “known to be used in ransomware campaigns” field is marked “unknown.” But the historical record is instructive. A BitSight report from March 2026 found that the threat actors behind the RondoDox DDoS botnet had incorporated the vulnerability into their arsenal just two days before public disclosure — a public proof-of-concept exploit was available almost immediately. Separately, Oligo documented a campaign dubbed ShadowRay 2.0, in which attackers compromised unpatched Ray clusters with NVIDIA GPUs and conscripted them into a self-replicating cryptocurrency-mining botnet.

The pattern is familiar to anyone who watched the original ShadowRay disclosures in 2023: internet-exposed, unauthenticated Ray clusters are a persistent magnet for opportunistic attackers, and AI infrastructure has a patching discipline problem. Ray is deployed by ML engineers, not security teams; development and testing instances spin up quickly, sit on corporate networks, and are rarely inventoried as production systems. That is precisely the population of machines this browser-based attack is designed to reach.

Why three days?

The accelerated deadline comes under Binding Operational Directive 26-04, which allows CISA to impose a three-day remediation window on vulnerabilities it deems especially risky. While the directive technically binds only Federal Civilian Executive Branch agencies, the KEV catalog functions as a de facto patching SLA across the private sector as well — compliance frameworks, cyber insurers, and enterprise procurement teams all treat KEV listings as a tripwire.

The urgency is easy to rationalize even without CISA’s specifics. The vulnerable population is enormous (hundreds of millions of downloads, a large unpatched tail), the attack requires only that a developer browse the web with the wrong browser, the PoC has been public for nine months, and active botnet campaigns are already documented. For any organization running Ray clusters on an internal network, the realistic threat model is not a sophisticated APT — it’s one developer clicking one bad ad.

What to do now

The guidance is straightforward:

• Upgrade to Ray 2.52.0 or later on every development, testing, and production deployment — not just internet-facing ones. Internal clusters are the primary target of the confused-deputy variant.
• Inventory Ray usage across the organization. Because Ray is often installed as a transitive dependency of ML tooling, many security teams don’t know it’s there.
• Enable token-based authentication introduced in 2.52.0, and treat it as defense-in-depth — not a replacement for network isolation.
• Keep Ray clusters off developer laptops’ default configurations where possible, and segment them from general corporate networks.

The bigger picture

CVE-2025-62593 is a small vulnerability with a large lesson. The AI boom has distributed powerful, poorly-authenticated compute infrastructure across millions of developer machines and corporate networks, faster than security practices have adapted. Ray did what open-source infrastructure always does — it optimized for usability and trusted the network boundary. But the boundary that matters now is the browser tab, and the attack surface is every ML engineer’s laptop.

CISA’s three-day clock expires August 20. For everyone else running Ray, the sensible assumption is that the clock already started nine months ago.

---

Sources are listed in the article metadata. Ray security advisories are available via the project’s GitHub advisory database (GHSA-q279-jhrf-cc6v).