Ray's browser guard was one string comparison

CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog on August 17, 2026 and set the remediation deadline at August 20 [5]. Three days, for a flaw in Ray, the compute framework underneath a great deal of AI training and inference. I went looking for what was so urgent.

The security control that failed reads, in full, as a check on whether the User-Agent header starts with the string “Mozilla” [1].

That is not a summary. It is the entire guard, and Ray’s own comment above it called the heuristic very weak [1].

The CVE number says 2025, and that deserves addressing before anything else. Ray shipped the fix on November 21, 2025, which is 271 days before the deadline CISA has just set, and eight further releases have gone out since [1][2]. Nothing about the vulnerability is new. What is new is the confirmation that people are being exploited through it, which is two days old, and the deadline attached to that confirmation, which expires on August 20.

Two things came out of pulling the thread, and the second matters more than the CVE.

What happened

CVE-2025-62593 is a remote code execution flaw in Ray before version 2.52.0 [3]. The advisory was published on November 26, 2025, and CISA added it to the Known Exploited Vulnerabilities catalog on August 17, 2026, with a remediation deadline of August 20 [1][5].

Ray’s dashboard exposes endpoints that submit jobs, and those endpoints have no authentication. The project knew browsers were a threat to that arrangement and shipped a guard against them. The guard tested the User-Agent header [1].

The problem is that page script can set that header. Combined with DNS rebinding, which makes a browser treat an attacker’s domain and a local service as the same origin, a developer who visits a malicious page or is served a malicious advertisement can have code executed on their own machine [1][3]. Oligo’s Avi Lumelsky is credited with the header bypass and Jonathan Leitschuh with the rebinding method [9].

Note what this is not. It does not require Ray to be exposed to the internet. It targets the copy running on a laptop, on loopback, which is the configuration most teams consider the safe one.

The scores disagree, and it is worth knowing why

NIST rates this 8.8 under CVSS 3.1. GitHub rates it 9.4 under CVSS 4.0 [3]. Both are genuine; they are different scales, and the 9.4 that appears in headlines is the newer one. Both vectors record that user interaction is required, because somebody has to visit the page. That does not make it unimportant. It does mean “critical unauthenticated RCE” oversells it slightly.

Why this matters

Loopback is not a security boundary when a browser is in the room. The mental model that binding to 127.0.0.1 protects a service is load bearing in a lot of developer tooling, and it holds only against attackers on the network. It does not hold against a browser, because the browser is already inside. Every local dashboard, debug port and agent API on a developer machine inherits this problem.

Nine months of patch availability did not close it. On August 18 I wrote about a vCenter flaw where the gap between a fix shipping and mass exploitation was five days. This is the same failure measured from the other end. Ray’s fix has been available since November 2025, through eight later releases, and CISA has still had cause to add the CVE to a catalog that exists for things being exploited now. One of those stories is about how fast attackers move. This one is about how long a patched flaw stays exploitable in practice, and that number is set by upgrade behaviour rather than by anyone’s release engineering.

The population is not small. Ray drew more than 62 million downloads from PyPI in the last thirty days, and the project’s Docker image has passed 20 million pulls [10][11]. Treat both as activity rather than headcount, because CI pipelines, mirrors and image rebuilds dominate those numbers and nobody should pretend otherwise. What they establish is the order of magnitude. This is not a niche package with a handful of installs on research machines.

The vulnerability in the catalog is not the one in the botnet. This is the part I did not expect. Reporting has connected this CVE to ShadowRay 2.0, the campaign that turned Ray clusters into a self-propagating cryptomining and DDoS botnet [9]. Oligo’s own writeup names a different vulnerability: CVE-2023-48022, the missing authentication on the jobs API, exploited against Ray dashboards reachable from the internet [7]. Oligo counts more than 200,000 exposed Ray servers, a tenfold rise on their 2024 figure [7].

CVE-2023-48022 is not in the KEV catalog. I checked the feed directly rather than trusting the coverage [5].

So the state of play is this. The flaw CISA is telling agencies to fix in three days is the browser one. The flaw driving mass exploitation is the older one, which carries a 9.8 score, is formally tagged disputed in the national vulnerability database, and is absent from the catalog entirely [4][5].

Technical breakdown

The two vulnerabilities share a root cause and differ in everything else.

CVE-2023-48022 is the jobs API accepting work without authentication. The vendor position recorded in the CVE entry is that the report is irrelevant, because Ray is not intended for use outside a strictly controlled network environment [4]. The project’s security documentation states the same premise plainly: Ray expects to run in a safe network environment [8]. Exploiting it requires reaching the dashboard, which is why exposure is the precondition and why the fix is network placement rather than a patch.

CVE-2025-62593 is what happens when that premise meets a web browser. The developer’s machine is inside the safe network. So is the browser. So, by extension, is any page the browser loads.

The three breaks are the ones a defender can actually operate. Resolver-level rebinding protection is the general control and it protects every local service, not only Ray. The upgrade is the specific one.

What the fix actually changed

I read the commit rather than the release notes [2]. It adds a check for the presence of any Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-Site or Sec-Fetch-User header, and rejects the request if one is found. The old User-Agent test stays in place behind it.

This is the right primitive. Those headers are set by the browser and page script is forbidden from setting or removing them, which is exactly the property User-Agent lacks. The fix is eighteen lines [2].

The thing I got wrong

I started from the assumption that a three-day remediation deadline was extraordinary and meant CISA knew something it was not publishing. So I measured it. Across the 63 entries added to the catalog since June 1, 2026, fifty-two carry a three-day deadline and eleven carry fourteen. Not one carries the twenty-one days that covered 226 of the 245 entries added during 2025 [5].

The deadline is not a signal about Ray. It is the new directive, BOD 26-04, which supersedes the 2021 directive that established the catalog [6]. The urgency I went looking for was a policy change I had not registered. Worth knowing if you have a KEV-driven process built around a three-week clock, because that clock is now three days.

CISA states evidence of active exploitation for CVE-2025-62593 and publishes no detail [5]. I could not find a public account of this specific CVE being exploited at scale. Reporting notes that the RondoDox botnet adopted it shortly before public disclosure, citing a BitSight report I was not able to open, so I am passing that along at one remove rather than asserting it [9].

What defenders should do Monday morning

Immediate, within 24 hours. Find out whether Ray is installed anywhere, including on laptops, and treat pip and conda environments as in scope. This is usually a data science decision that never reached an asset inventory. Upgrade to 2.52.0 or later [1].

Near term, this week. Turn on DNS rebinding protection at your resolvers, and confirm it rather than assume it, since it protects every local service your developers run. Then check whether any Ray dashboard answers from outside your network. If one does, you are exposed to CVE-2023-48022, which no patch closes. Ray 2.52.0 makes token authentication available, so enable it [4].

If you want to know whether this already happened, the useful artifact is Ray’s own job history. A job nobody on the team submitted is the finding, and unlike most of what a browser does to a machine, it is written down. Pair that with outbound network connections originating from Ray worker processes on a laptop, which is not a thing local development normally produces. Neither check is conclusive on its own. Both are cheap, and on a developer machine the volume is low enough that anomalies are legible rather than buried.

Structural, this quarter. Write down which locally bound developer services exist and stop treating loopback as an access control. If your patching process keys off KEV membership, reset the expected window from twenty-one days to three [5][6], and add a second trigger for critical flaws that never reach the catalog, because CVE-2023-48022 is the demonstration that some never do.

Checklist

• Ray inventoried across servers, containers and developer laptops
• Ray upgraded to 2.52.0 or later
• Token authentication enabled on Ray, available from 2.52.0
• No Ray dashboard reachable from outside the network
• DNS rebinding protection enabled at the resolver, and verified
• Alerting for external domains resolving into loopback or RFC1918 space
• Locally bound developer services inventoried and treated as attack surface
• KEV-driven patch SLAs updated from twenty-one days to three
• A second prioritisation trigger that does not depend on KEV membership

Disputed is not the same as wrong

CVE-2023-48022 has carried a dispute tag since 2023. The vendor’s argument is that running Ray outside a controlled network is a deployment error rather than a vulnerability [4]. As a statement about design intent, that is coherent, and Ray is not unusual in making it. Plenty of infrastructure assumes a trusted network.

As a security outcome it has been settled by measurement. More than 200,000 exposed servers and a self-propagating botnet [7] is what “users will deploy it correctly” looks like when it meets a default that does not enforce anything. The dispute did not make the software safer. It moved the argument off the CVE record and into everyone else’s incident queue.

The detail I keep returning to is the calendar. CVE-2023-48022 was published on November 28, 2023, and disputed on the grounds that Ray assumes a controlled network [4]. Token authentication for the dashboard was merged on November 7, 2025 [12]. That is 711 days, near enough two years to the week.

The browser guard fix was merged seven days after it [2]. Both shipped in 2.52.0 [1][4].

So the release that patched the browser bypass is also the release where the control the project had spent two years calling somebody else’s responsibility arrived anyway, in the same version bump, without the dispute ever being withdrawn.

That is the pattern worth naming, and it is not specific to one project. When a maintainer disputes a CVE on the grounds that correct deployment prevents it, the useful question is not whether they are right about the design. It is whether the default configuration makes the correct deployment the likely one. If it does not, the dispute is a statement about whose fault the breach will be, which is a different thing from a control.