CVE-2025-62593: One Web Page Can Hijack a Ray Developer's Laptop

A vulnerability in Ray, the distributed computing framework behind large-scale AI and machine learning workloads, is being used in real attacks according to the US Cybersecurity and Infrastructure Security Agency. On August 17, 2026, CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities (KEV) catalog, giving US federal agencies a remediation deadline of August 20 — three days later.

What makes this one awkward is that the target is not a server. It is the developer's own machine. Keep Ray running, open a page the attacker controls in Firefox or Safari, or simply get served a malicious ad on that page, and attacker code runs on your laptop. No click, no download, no dialog to approve. The fix landed in 2.52.0 back in November 2025, and the latest release as of August 2026 is 2.57.0.

Updating is not the end of it. Ray has carried a design decision — no authentication on the dashboard or the job submission endpoint — for almost three years, and a botnet is still working that door today. This article covers what CVE-2025-62593 actually does, the larger problem sitting behind it, and every other Ray vulnerability worth tracking.

Who goes after this, and what happens on your machine

The people reaching for this flaw want engineers at AI and machine learning companies, taken over along with the machine they work on. Grabbing one developer endpoint is faster than attacking a company's servers head-on. A developer's laptop holds cloud keys, credentials for internal systems, half-written source code and models in training. The delivery method is an ordinary-looking web page, or an ad slipped into an ad slot. If the target is a specific company, a page dressed up as a technical article that its engineers would plausibly read does the job.

Once the page loads, it quietly sends instructions to the Ray process running on that machine and has it execute whatever commands the attacker wants. From the owner's side, it looks like a web page and nothing more. Nothing is downloaded and nothing is installed, so "I never opened a suspicious file" is not a defence here. The code runs with the privileges of whoever started Ray.

Damage does not stop at that one machine. From a developer endpoint an attacker can move sideways into internal Ray clusters and training servers, which opens the door to stealing training data and models, tampering with those models, and running up cloud bills. For end users, this arrives indirectly: the environment where the service they use is being built gets contaminated. That is why both steps below — updating, and switching authentication on yourself — matter.

How opening a page hands over your machine

CVE-2025-62593: driving Ray through the browser

Starting Ray brings up a dashboard on the machine itself, listening on localhost:8265 by default. That dashboard exposes /api/jobs and /api/job_agent/jobs/, and if you post a command to them, they run it. There is no authentication in front.

Normally a page open in your browser cannot fire commands at another program on the same machine. The same-origin policy, one of the basic rules browsers enforce, blocks that. This attack sidesteps it in two stages.

Stage one is impersonating the browser. Ray did have a crude guard against browser-originated requests, but the entire check was "reject the request if the client name attached to it (the User-Agent) starts with Mozilla". According to the vendor advisory, Firefox and Safari let page-side code rewrite that client name, so swapping in anything that does not start with "Mozilla" walks straight past the guard. Chrome cannot perform that rewrite because of an implementation difference, which is why it falls outside the affected set.

Stage two is DNS rebinding. This is a classic trick that abuses the system translating a site's address (its domain name) into a server's actual number (its IP address): the attacker flips their own domain's translation target mid-flight to 127.0.0.1, the machine itself. From the browser's point of view the address never changed, so it treats the traffic as staying inside the same site, and the page's scripts end up talking directly to the Ray process on that machine. The proof of concept used Singularity, the DNS rebinding test tool published by security firm NCC Group.

With both stages in place, researchers demonstrated command execution the moment the page opens, on Windows, macOS and Linux alike. The starting point was a note from Avi Lumelsky at the Israeli security firm Oligo Security about the client-name rewrite; Jonathan Leitschuh, then at Socket, built the DNS rebinding proof of concept and handled disclosure to the vendor. Leitschuh is the researcher who went public in 2019 about the hidden web server shipped with Zoom for Mac, and he has kept chasing the same shape of problem: developer tools listening locally, reachable from the browser. The risk of dev tooling holding a local port open also shows up in the open redirect flaw found in Jupyter Server.

Severity is 9.4 out of 10 ("critical") in the vendor's own scoring and 8.8 ("high") in NIST's NVD reassessment. The gap comes from how much weight each puts on the "the user opens a page" precondition. The practical outcome is identical: takeover.

Why a nine-month-old flaw is only now marked as exploited

CVE-2025-62593 was published on November 26, 2025. Nearly nine months passed before the KEV listing, and CISA has not stated publicly what evidence it acted on. Public reporting does, however, confirm that the flaw had already been built into attack code.

It appears in the analysis of the RondoDox botnet that security firm Bitsight published on March 11, 2026. RondoDox sprays exploits at internet-facing devices, and between May 25, 2025 and February 16, 2026 it used 174 distinct exploits covering 148 CVEs, peaking at 15,000 exploitation attempts in a single day. One of the weapons in that arsenal targets Ray.

The interesting part is that the implementation does not work. Report author João Godinho points out that RondoDox's Ray exploit sets the client name to Mozilla/5.0 (rondo2012@atomicmail[.]io), and writes:

Ray's guard rejects anything starting with "Mozilla", so the attacker announced themselves with a name that starts with Mozilla and got bounced by their own payload. Politely embedding a contact address in the client-name field turned out to be self-defeating. None of which makes this safe. The failure is one botnet's coding mistake, and changing a single character fixes it. Once a flaw is riding along in indiscriminate internet-wide scanning code, it has moved into the "known about and being tried" category.

The August 20 deadline comes from BOD 26-04, the directive CISA now runs in place of BOD 22-01. Instead of one flat timeline for everything in KEV, it scores each entry against four risk conditions, and anything meeting all four gets a three-day window. Ray landed in that shortest bracket. There is no legal force behind it outside US federal agencies, but "the US government told its agencies to fix this in three days" is a usable priority signal. You can search the full KEV catalog through our CISA KEV dashboard.

The real problem: 230,000 clusters sitting on the open internet

CVE-2025-62593 is a branch, not the trunk. The trunk is the absence of authentication on Ray's job submission API — something the project has long treated as intended behaviour.

CVE-2023-48022: an unauthenticated job API with no fix planned

Reported in 2023, CVE-2023-48022 notes that Ray's dashboard and job submission API ask nobody for credentials, so anyone who can reach them can execute commands. Ray's maintainers classified this not as a vulnerability but as "a design intended for use inside a trusted network" and declined to fix it. The CVE record carries a "disputed" status.

The trouble is that the assumption does not hold in the wild. In March 2024 Oligo Security disclosed ShadowRay, a campaign that had been taking over Ray clusters worldwide through exactly that design. In November 2025 the same firm reported the sequel, ShadowRay 2.0.

CVE-2025-34351: authentication exists, but ships switched off

Three days after ShadowRay 2.0 went public, on November 21, 2025, Ray 2.52.0 arrived with the long-awaited token authentication. In its announcement, maintainer Anyscale wrote that "secure-by-default is coming to Ray, and this is the first big step."

The official documentation, however, states plainly:

In other words, updating to 2.52.0 or later does not turn authentication on. You have to set the environment variable RAY_AUTH_MODE=token yourself. Leitschuh filed that state — a feature present but off — as its own issue, CVE-2025-34351, scored 10.0 out of 10 and published on November 26, 2025. There is no fixed version, because the answer is configuration. The release notes for 2.57.0, the latest as of August 2026, contain no sign of the default being flipped.

Ray is not alone in letting "authentication off by default" turn into incidents. The feature store Feast has seen a run of unauthenticated takeover flaws as well. Auditing what the defaults actually are in the components you depend on is worth pairing with the approach in our OSS supply chain scanner.

Are you affected? Version and usage table

Start with pip show ray to check your version, then find your row below.

For CVE-2025-62593 specifically, your browser changes the picture too. The more you browse normally while a local Ray instance is up, the larger your exposure.

That does not make Chrome a safeguard. You are being saved by an accident of browser implementation, and Ray's side of the guard is just as thin as before. Browsers are not the defence here; updating is.

What to do now

Four steps, in priority order. The first two are a pair — either one alone leaves you short.

To check whether you have already been hit, look for job executions you do not recognise, unexplained CPU or GPU load, and cron entries that phone out every fifteen minutes. In ShadowRay 2.0 the payload refreshed itself from GitLab and GitHub on a fifteen-minute cycle. And because the miner deliberately caps itself at 60% CPU, "it is not pegged at 100%, so we are fine" is not a conclusion you can draw.

How this unfolded

← Swipe to navigate

Every Ray vulnerability tracked here

The five issues covered in this article, ordered by how urgently they need attention.

Takeover just by loading data

The next set of flaws, found during 2026, work differently. Browsers and authentication are irrelevant here — the trigger is the act of loading externally sourced data into Ray.

CVE-2026-57516: a training .tar that executes on load

The cause is that the restore step trusts its input too much. Software routinely packs data into a compact form for storage or transfer and then unpacks it back into something usable — deserialization. Hand a crafted payload to that unpacking step and arbitrary code can run; Python's "pickle" mechanism is notorious for exactly this.

According to the vendor advisory, Ray's read_webdataset() restored file contents without any validation based on the extension. Specifically, .pickle and .pkl files went straight through pickle, while .pt and .pth files were read by torch.load() with its safety check turned off. Either one, if crafted, runs the attacker's code on the spot. Severity is 8.8 out of 10 and the fix is in 2.56.0.

The awkward part is that this restore step fires before you really start using the data. An entirely ordinary operation such as .take_all() or .iter_batches() is enough. The vendor lists the likely delivery routes for a malicious .tar: S3 buckets left writable by misconfiguration, publicly hosted WebDataset directories, dataset mirrors on Hugging Face Hub, and model zoo tarballs common in computer vision. All of them are places AI teams touch daily. Our article on the flaws in picklescan, a tool for detecting dangerous code in AI models, goes deeper into why the pickle format is risky.

This route does require the user to load a dataset the attacker prepared. Teams that only ever read their own trusted data are much less exposed. That said, pulling in public datasets and third-party models is completely routine in AI work. A distributor you trusted may have been compromised, or a mirror may be serving a fake. Treat anything you pull in from outside as a program that can run — that is the baseline posture here.

CVE-2026-41486: the same hole in Parquet loading

CVE-2026-57516 was not a one-off. Immediately before it, CVE-2026-41486 covered Parquet files being restored through cloudpickle without checks, fixed in 2.55.0. Different format, same root: data arriving from outside gets restored in a form that can execute.

From an engineer's perspective this is less a Ray-specific bug than the consequence of leaning on convenient-but-dangerous restore mechanisms like pickle and torch.load across every data ingestion path. Fixing one path leaves the same hazard sitting in the next format, which is why these keep recurring. The same pattern shows up elsewhere in AI infrastructure: the feature store Feast has had takeover flaws from unsafe restore logic as well. Practically, the answer is to limit where datasets and models come from, switch to safe loading modes where possible, and run training in an isolated environment with tight network and filesystem access.

What Ray actually is

Ray is an open source framework that takes Python programs and AI workloads written for one machine and spreads them across many servers with minimal changes. It came out of UC Berkeley and is now developed primarily by Anyscale. It handles distributing data-heavy model training and production inference efficiently across a fleet.

Adoption is broad: over 40,000 stars on GitHub and more than 10 million downloads a week. OpenAI reportedly used Ray to tune ChatGPT's training, and Uber, Spotify, Netflix and ByteDance all run it in their AI stacks. Because it exists to bind together expensive GPU-equipped servers, a compromised Ray cluster is unusually valuable, which makes it a high-return target. That is exactly why ShadowRay 2.0 ended up on a cluster worth roughly $4 million a year in compute.

Summary

CVE-2025-62593 lets an attacker run code on a developer's machine when that developer opens a malicious page in Firefox or Safari while Ray is running. CISA added it to the Known Exploited Vulnerabilities catalog on August 17, 2026, with a remediation deadline of August 20 for US federal agencies. The fix is in 2.52.0; the latest release is 2.57.0.

With Ray, though, updating is not sufficient. The absence of authentication on the job submission API remains in place as intended behaviour, and a botnet is scanning more than 230,000 exposed clusters through it. The token authentication added in 2.52.0 is still off by default. Update, then set one environment variable and turn authentication on yourself. Those two things are what anyone running Ray should do right now. Start with pip show ray.

References

• ▸CISA Adds One Known Exploited Vulnerability to Catalog (CISA, August 17, 2026)
• ▸Ray Security Advisory - GHSA-q279-jhrf-cc6v (primary source for CVE-2025-62593)
• ▸NVD - CVE-2025-62593 Detail (NIST)
• ▸Ray: New Token Authentication is Disabled By Default (CVE-2025-34351)
• ▸ShadowRay 2.0 (Oligo Security, November 2025)
• ▸RondoDox Botnet Infrastructure Analysis (Bitsight, March 11, 2026)
• ▸Ray token authentication (official documentation)
• ▸Introducing Token-Based Authentication for Ray (Anyscale)
• ▸BOD 26-04: Prioritizing Security Updates Based on Risk (CISA)
• ▸Ray Security Advisory - GHSA-hhrp-gw25-jr43 (CVE-2026-57516)
• ▸Ray Security Advisory - GHSA-mw35-8rx3-xf9r (CVE-2026-41486)
• ▸PyPI - ray (releases)