Ray CVE made the developer laptop the target
August 25, 2026
The Ray CVE on CISA's three-day clock is a developer browser, not a cluster login. NVD published CVE-2025-62593 on 26 November 2025 as a Firefox and Safari hit against developers working with Ray as a development tool. CISA added it to KEV on 17 August 2026, due 20 August. That calendar is a laptop. The cluster drawing in the docs did not get the invite.
Ray's docs still describe a cluster#

Ray's security page is blunt about the product. "Ray expects to run in a safe network environment and to act upon trusted code." Dashboard, Jobs, and Client are developer tools. Isolation is supposed to live outside the cluster. The same page says anybody who can reach those ports can run arbitrary code, explicitly, indirectly, or by unpickling something ugly.
That is a coherent story if the box is a locked GPU farm. NVD's writeup of CVE-2023-48022 still carries the vendor NOTE that a remote Job API RCE is "irrelevant" because Ray is not meant for use outside a strictly controlled network. CVSS 9.8. Disputed. Same Jobs surface. Different sermon about whose network.
The disputed tag is doing a lot of work for a dashboard that prints a laptop URL by default. When you start a single-node cluster, Ray prints http://localhost:8265. The danger line in the dashboard docs says do not expose that UI publicly. Localhost is not public. Localhost is also where the browser sits.
CISA scheduled a developer machine#

The KEV row is short on purpose. CISA did not write a cluster postmortem. It wrote a catalog line.
- Vendor is Ray-Project, product Ray.
- Added 17 August 2026, due 20 August 2026.
- Ransomware campaign use is Unknown.
- Forensic triage required per BOD-26-04 is no.
The shortDescription is the tell. "Developers using Ray as a development tool may be exposed to this vulnerability exploitable through Firefox and Safari."
CISA's 17 August alert listed one CVE and said the add was "based on evidence of active exploitation." On the NVD page, CISA's SSVC flag flipped from poc to active the same morning. The Register called the window three days rather than the usual fourteen, and pointed at BOD 26-04 as the rule that allows that squeeze.
Federal civilian agencies had until 20 August. This is after that date. The clock is not the remaining plot. The asset on the calendar is.
A Mozilla prefix is not a wall#

The guard was a string check. If User-Agent starts with Mozilla, treat the caller as a browser and refuse the write. The Ray advisory says that out loud. It also says the fetch spec lets Firefox and Safari set User-Agent to something else.
So the name tag on the door said browsers keep out. The browsers that follow the spec can peel the tag off. DNS rebinding does the rest. A page you meant to read, or an ad you did not, talks to the local dashboard after the rebind as if it belonged there.
GHSA's impact line is the one that should rearrange the furniture. "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 follow-up is uglier. That same browser can be a confused deputy into a Ray instance on the LAN you still think of as the real cluster.
This is not a cluster login. There is no bastion. There is a laptop running Ray, a browser on the same desk, and a Jobs API that believed a header. The default is http://localhost:8265. Binding on 127.0.0.1 is supposed to feel like a lock. It is a lock against the open internet. It is not a lock against the other window.
Chrome sits this one out because of a fetch bug. Out of spec, accidentally. That is a coincidence, not a control. Do not ask for the aiming instructions. The advisory already shipped a full reproduction. The useful fact is the shape.
2.52.0 closes the hole and leaves auth off#

NVD's CPE is Anyscale Ray, versions up to excluding 2.52.0. The advisory matches it. Affected, below 2.52.0. Patched, 2.52.0. Anything older is still the Mozilla sticker.
The same line adds token auth. Ray's token-auth docs say it is available in 2.52.0 or later, and "Authentication is disabled by default in Ray 2.52.0." They also say it is not an alternative to a controlled network.
So you patch. You should. You do not get a product out of the upgrade. You get a closed hole and a dark switch.
- The hole this CVE names is closed in 2.52.0.
- Token auth exists on that same line and starts off.
- Chrome's fetch quirk is still not a Ray control.
- A laptop running older Ray is still the KEV asset.
If pip show ray is still sitting under 2.52.0, the Mozilla sticker is still on the door. You'll hit this if Ray is running locally and Firefox or Safari is open on the same user. That is the asset CISA catalogued.
The agent box is already in production#

Red Hat kept the severity at Important because a hit needs a click plus rebinding. Fair as a score. CISA still burned a three-day KEV slot on the same CVE. Both can be true. The steel-man is the click. The miss is calling the box a workstation after an agent lives on it.
The Hugging Face break-in was the other failure, a store the next eval could read. This one is closer. The box already logged in, sitting next to a browser, is the thing on the calendar.
Upgrade and you close this browser pathPATHThe shell environment variable listing directories searched in order when a command name is typed, so every lookup walks each entry until one matches.See also WSLENV, appendWindowsPath, command lookup. Turn on token auth and you add depth. Neither step makes a development machine that shares a session with Firefox sit outside the threat model. If the runtime can submit Jobs, the laptop is in production.
Questions the KEV entry actually raises
Which Ray version actually patches this?
NVD and the GitHub advisory both draw the line at 2.52.0. Every earlier Ray is in the affected set. That is the upgrade, not a config flag and not a browser swap.
asked on daily.dev ↗Does Chrome make an unpatched Ray safe?
The advisory says Chrome happens not to let fetch rewrite User-Agent, out of spec with the fetch rules Firefox and Safari follow. That is a browser quirk, not a Ray patch. An old Jobs API is still an old Jobs API if something other than that Chrome fetch path reaches it.
asked on github.com ↗Why did Red Hat keep this at Important instead of Critical?
Red Hat said a successful hit needs user interaction plus DNS rebinding, so they scored it Important at 8.8. CISA still put the same CVE on KEV with a three-day federal due date. The click is real. The target is still the developer machine.
asked on access.redhat.com ↗Is this the same class of bug as the old cluster Job API CVE?
CVE-2023-48022 is the disputed cluster cousin. The vendor called that report irrelevant because Ray is documented for a strictly controlled network. This one reuses the Jobs surface and reaches it through a browser on the box that is running Ray.
asked on nvd.nist.gov ↗Did 2.52.0 turn authentication on by default?
No. Token auth arrives in 2.52.0 and Ray's own docs say it is disabled by default. They also say it is not a substitute for a controlled network. The patch closes this browser path. It does not reclassify your laptop.
asked on docs.ray.io ↗Did CISA say ransomware is using this?
The KEV row marks known ransomware campaign use as Unknown. The catalog addition is still based on evidence of active exploitation. Do not wait for a ransomware flag to treat a local Ray as in-scope.
asked on cisa.gov ↗