CISA imposes three-day fix deadline on actively exploited Ray framework RCE flaw

A critical remote code execution vulnerability in the Ray distributed computing framework is under active exploitation, with CISA giving federal agencies just 72 hours to patch.

AI-generated illustration depicting vulnerability for the story: CISA imposes three-day fix deadline on actively exploited Ray framework RCE flaw

Summary

  • CVE-2025-62593 (CVSS v4: 9.4) allows remote code execution against Ray installations via a DNS rebinding attack using Firefox or Safari’s Fetch API.
  • A developer simply visiting a malicious website or receiving a malicious ad can trigger the exploit, which can then pivot to attack Ray instances inside a corporate network.
  • CISA has given US federal civilian agencies three days to remediate — well below the standard 14-day window — under Binding Operational Directive 26-04.
  • Ray 2.52.0 patches the vulnerability and introduces optional token-based authentication, though that feature remains disabled by default.
  • Ray is used by an estimated 60 percent of Fortune 500 companies and records roughly seven million downloads per week, making the exposure significant.

The vulnerability

CVE-2025-62593 was first disclosed in November 2025 and carries a CVSS v4 score of 9.4. The flaw exists in how vulnerable versions of Ray attempt to distinguish browser requests from other traffic: the framework checks whether the incoming User-Agent header begins with “Mozilla” and blocks requests that match on that basis. The problem is that Firefox and Safari both permit scripts using the Fetch API to modify that header, effectively letting an attacker spoof a non-browser client and reach Ray’s unauthenticated endpoints.

How an attack unfolds

The attack chain relies on DNS rebinding. A developer running Ray on their machine visits a compromised or malicious website — or is served a malicious advertisement — in an affected browser. A script on that page can then use DNS rebinding to reach the local Ray service and execute arbitrary shell code on the developer’s machine. The Ray project’s own advisory notes a second, more concerning path: the browser can act as a “confused deputy” intermediary, allowing the same technique to reach Ray instances running inside a private corporate network. That means a single developer’s browser session could become the entry point for an attack on internal ML infrastructure.

Why CISA shortened the window

CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue and gave US federal civilian executive branch agencies three days to remediate, rather than the standard 14. The agency did not publicly explain the accelerated timeline and marked the ransomware campaign field as “unknown.” The shorter deadline is permitted under Binding Operational Directive 26-04, which allows CISA to impose a 72-hour window on vulnerabilities it considers especially risky. Whether CISA has observed exploitation activity beyond what is publicly known remains unclear from the available sources.

The authentication gap at Ray’s core

The security advisory points to Ray’s historical lack of authentication on critical endpoints as the root enabler. Ray was designed with the assumption that clusters would run inside a trusted, isolated network, with access control left to surrounding infrastructure rather than the framework itself. That design philosophy worked well enough in tightly controlled environments but creates meaningful exposure wherever that perimeter assumption does not hold — including developer laptops and corporate networks where Ray instances may be reachable from a browser. Ray 2.52.0 introduces optional token-based authentication as a supplementary control, but it is disabled by default. The project continues to recommend network isolation as the primary defence, not authentication alone.

Scale of exposure

Ray is a widely deployed framework. Managed by the Linux Foundation’s PyTorch Foundation, it originated at UC Berkeley and was commercialised by Anyscale in 2019. As of October 2025, it had accumulated more than 237 million total downloads, with approximately seven million per week — growth of roughly tenfold year-on-year. Product analysis site NextSprints estimates one million monthly active users and adoption by 60 percent of Fortune 500 companies. That footprint, combined with the ML and Python workload context in which Ray typically runs, makes the potential value of a successful exploit — access to model training infrastructure, sensitive data pipelines, and developer environments — considerable.

Why it matters

Ray sits at the intersection of developer tooling and machine learning infrastructure, two areas where security controls have historically lagged behind deployment pace. The attack vector here is low-friction: no special access required, just a developer browsing the web in Firefox or Safari. The internal network pivot capability is the more serious concern for enterprise CISOs — if Ray is running anywhere inside a corporate network without network isolation, a single compromised browser session may be sufficient to reach it. With CISA treating this as a 72-hour priority and exploitation confirmed as active, organisations running Ray in any environment should treat this as an immediate operational risk, not a scheduled patch cycle item.

What to do now

  • Upgrade all Ray deployments to version 2.52.0 immediately.
  • Enable the optional token-based authentication introduced in Ray 2.52.0 as an additional control layer.
  • Audit your environment to confirm Ray clusters are deployed inside a controlled, isolated network and are not reachable from general developer workstations or the internet.
  • Remind developers running local Ray instances to exercise caution with browser activity, particularly in Firefox and Safari, until patching is confirmed.
  • Review whether Ray instances exist inside your corporate network that may be reachable via browser-based DNS rebinding from any network-connected endpoint.

Sources