A Ray AI-framework bug got a rare three-day federal patch order. Here is what CVE-2025-62593 actually is, and what it is not

When CISA gives a vulnerability a three-day patch deadline, it is worth paying attention, because that is short even by the agency's standards. But the Ray flaw behind this one is a good example of how a real, critical bug can get wrapped in numbers that actually belong to a different vulnerability. Let us separate the two.

What CISA actually did

On 17 August 2026, CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog, the list of flaws the agency says are being exploited in the wild. The entry sets a due date of 20 August, giving US federal civilian agencies roughly three days to apply mitigations or stop using the product. Legacy KEV deadlines were typically two to three weeks, so three days is aggressive by that standard. It reflects a newer, risk-based patching directive under which the highest-risk, actively-exploited flaws get the tightest windows, rather than the old fixed-window model, so a deadline this short is less a one-off than a signal of where CISA has placed this bug.

Ray is the software in question: an open-source framework, maintained by the company Anyscale, that developers use to scale Python applications and AI workloads across many machines. It is widely used in machine-learning infrastructure, which is why a critical bug in it draws this level of attention.

What the vulnerability really is

Here is the part that gets oversimplified. Per the ray-project security advisory and its entry in the national vulnerability database, CVE-2025-62593 is a browser-driven attack on a developer's own machine, not a remote internet-scanning attack on servers.

Ray's dashboard exposes a jobs API that can run code, and it tried to protect that API from being triggered by a web browser using a weak check: it looked at the request's User-Agent header and rejected anything starting with "Mozilla," on the assumption that a browser could not change that header. That assumption is wrong. In Firefox and Safari, the fetch API lets a web page set the User-Agent to whatever it wants, defeating the check. Combine that with a DNS-rebinding technique, which lets a malicious website's code talk to a service running on the victim's own computer, and a developer who simply visits a booby-trapped web page while running Ray locally could have a job submitted to their dashboard, and that means arbitrary code execution on their machine.

The flaw carries a CVSS 9.4 (critical) score under the newer v4.0 scale (and 8.8 under v3.1). Notably, it requires user interaction: the victim has to load the malicious page. It was reported by a researcher at Socket, credited to a finder at the security firm Oligo, and is fixed in Ray 2.52.0; all earlier versions are affected.

One more piece of context that explains the shape of the fix: the Ray maintainers have long taken the position that Ray is meant to run trusted code inside a trusted network, and have deliberately not put authentication on some critical endpoints. The 2.52.0 release closes the browser-bypass trick and adds an authentication feature, but that feature is opt-in and off by default, consistent with that philosophy.

The numbers that are not about this bug

If you have seen figures like "200,000 exposed Ray servers," "a self-propagating botnet," or "millions of dollars of stolen compute for cryptomining," those are real, but they describe a different vulnerability. They come from security firm Oligo's "ShadowRay" and "ShadowRay 2.0" research into CVE-2023-48022, an older flaw that is an unauthenticated remote code execution in Ray's jobs API, exploitable directly against Ray clusters left exposed to the internet. (It is a flaw whose report the Ray maintainers have formally disputed, on the same "Ray is meant to run inside a trusted network" grounds, even as it has been exploited in the wild.)

That is a fundamentally different attack surface from CVE-2025-62593:

• CVE-2023-48022 (ShadowRay): attackers scan the internet for exposed Ray clusters and run code on them directly, no user interaction needed. This is the one tied to the hundreds of thousands of exposed servers, hijacked GPUs and cryptomining botnet.
• CVE-2025-62593 (this week's KEV entry): a malicious web page reaches a developer's local Ray dashboard through their browser, and the developer has to visit the page. Narrower, and aimed at individual developer machines rather than exposed fleets.

Conflating the two makes CVE-2025-62593 sound like an internet-wide server massacre. It is not; it is a clever browser-based path to code execution on the machines of developers who run Ray locally.

How solid is "actively exploited"?

CISA's KEV catalog is, by definition, a list of exploited vulnerabilities, and adding CVE-2025-62593 is the agency's assertion that it is being used in attacks. Worth being straight about the evidence, though: CISA has not published technical details or indicators for exploitation of this specific CVE. The clearest public telemetry tied to it comes from a scanning botnet that added it to its toolkit around the time of disclosure, but that evidence sits awkwardly with the bug itself. This flaw is not something a botnet can simply spray at exposed endpoints: exploiting it requires luring a developer into loading a malicious page in their own browser, not hitting a server directly. And the observed attempts set a User-Agent beginning with "Mozilla," the very prefix Ray's flawed check rejects, so they would likely have been blocked anyway. Direct, browser-style requests like that look more like the indiscriminate scanning associated with the older CVE-2023-48022 than like genuine exploitation of this browser-driven bug. In other words, "under active exploitation" here is CISA's determination, not something independently and richly documented in public. That is not a reason to ignore a three-day federal order; it is a reason to describe the threat accurately rather than dramatise it.

What to do

The remedy is simple and worth stating plainly: upgrade to Ray 2.52.0 or later. If you run Ray, especially in a local development setup where you also browse the web on the same machine, that update removes the browser-bypass path. As defence in depth, do not expose Ray dashboards or its jobs API to untrusted networks, and consider turning on the new authentication option. And treat the older ShadowRay flaw (CVE-2023-48022) as a separate item on your list: if you operate Ray clusters, make sure none are reachable from the open internet.

The flaw at a glance

CVE	CVE-2025-62593, in Ray (open-source AI-compute framework, maintained by Anyscale)
Added to CISA KEV	17 August 2026, due date 20 August (rare ~3-day window)
Severity	Critical, CVSS 9.4 (v4.0) / 8.8 (v3.1)
How it works	Browser User-Agent check bypass (Firefox/Safari) + DNS rebinding to reach a developer's local Ray dashboard and run a job
Requires	The developer to visit a malicious web page (user interaction)
Fixed in	Ray 2.52.0 (adds opt-in, off-by-default authentication)
Exploitation	CISA asserts active exploitation but has released no technical detail or IOCs for it; only limited third-party telemetry exists
Do not confuse with	CVE-2023-48022 (ShadowRay), the older unauthenticated flaw behind the 200,000+ exposed-server, cryptomining figures

Frequently asked questions

What is Ray?

Ray is an open-source framework, maintained by the company Anyscale, for scaling Python programs and AI/machine-learning workloads across many machines. It is common in ML infrastructure, which is why a critical vulnerability in it draws wide attention.

What does CVE-2025-62593 let an attacker do?

Run code on a developer's machine. Ray's dashboard tried to block browser requests by checking the User-Agent header, but Firefox and Safari let a web page override that header. Combined with a DNS-rebinding trick, a malicious site the developer visits can reach their locally running Ray dashboard and submit a job, resulting in code execution. It requires the developer to load the malicious page.

How do I fix it?

Upgrade to Ray 2.52.0 or later, which removes the bypass and adds an optional authentication feature. Also avoid exposing Ray's dashboard or jobs API to untrusted networks.

Is this the flaw behind the "hundreds of thousands of exposed Ray servers" stories?

No. Those figures come from CVE-2023-48022 (Oligo's "ShadowRay" research), a separate, older unauthenticated flaw exploited directly against internet-exposed Ray clusters. CVE-2025-62593 is a narrower browser-based attack on individual developer machines. They are different vulnerabilities with different fixes.

Is it really being actively exploited?

CISA lists it as exploited, which is the basis for the three-day deadline, but the agency has not published technical details for this specific CVE. The clearest public data tied to this exact bug involved attack attempts that would likely have been blocked by Ray's own (flawed) check. Patching is still the right move; just treat "actively exploited" as CISA's assessment rather than a heavily documented public fact.