CVE-2025-62593

What is Ray?

Ray (ray-project, stewarded by Anyscale) is an open-source distributed compute engine for AI and ML workloads — sometimes described as "the Kubernetes of AI." It schedules training, inference, and data-processing jobs across clusters of machines, and its Jobs API is designed to accept and execute arbitrary user-supplied code.

Ray ships with no authentication on its critical endpoints (/api/jobs, /api/job_agent/jobs/), a longstanding upstream design decision justified on the grounds that Ray is documented as requiring a trusted network. Ray clusters typically hold model weights, training data, cloud credentials, and substantial GPU capacity — a combination attractive to both data thieves and cryptojackers, and one that has already drawn sustained in-the-wild attention.

Overview

CVE-2025-62593 lets an attacker-controlled web page reach a Ray instance that is not exposed to the network at all — including one bound only to localhost on a developer's own workstation — and submit a job that executes arbitrary code.

Ray's defence against browser-originated attacks was a User-Agent header check: reject requests whose User-Agent begins with "Mozilla". That guard does not hold. The fetch specification permits scripts to set the User-Agent header, and Firefox and Safari implement it to spec. Combined with DNS rebinding to defeat the same-origin policy, an attacker's page can reach 127.0.0.1 and drive Ray's unauthenticated job submission API.

The practical significance is that this defeats the "it's fine, it's only bound to localhost" mitigation that had long been used to justify Ray's unauthenticated-by-default posture.

Affected Versions

The fix landed in commit 70e7c72780bdec075dba6cad1afe0832772bfe09. Container images that bundle Ray inherit the vulnerability and must be rebuilt against 2.52.0 or later.

Technical Details

The attack chain has four steps:

1. The attacker lures a developer to a malicious page — a phishing link or malvertising is sufficient. The page must be opened in Firefox or Safari.
2. The page overrides the User-Agent header on a fetch() call. Ray's only browser-origin guard rejects requests whose User-Agent starts with Mozilla, so setting anything else walks straight past it. Chrome happens to block this header override, but only because of an out-of-spec implementation quirk — not a deliberate protection, and not something to rely on.
3. DNS rebinding defeats the same-origin policy. The attacker's domain re-resolves to 127.0.0.1, so the browser treats requests to the developer's local Ray instance as same-origin and permits them.
4. The request hits /api/jobs or /api/job_agent/jobs/, which accept a job definition containing an arbitrary shell command — yielding code execution on the developer's machine.

CWE-94 in this context: there is no memory-safety or parsing bug here. The "code injection" is the Jobs API working exactly as designed; the vulnerability is that a bypassed access guard exposes it to an untrusted origin. The GitHub advisory assigns both CWE-94 (code injection) and CWE-352 (cross-site request forgery), and CWE-352 is arguably the more descriptive of the two.

Attack characteristics:

• Authentication required: none.
• User interaction required: yes — the victim must visit an attacker-controlled page. This is what holds the NVD CVSS v3.1 score to 8.8; the GitHub advisory's CVSS v4.0 score is 9.4.
• Attack complexity: low, though it requires the multi-step rebinding chain and a Firefox or Safari victim.
• Primary victim: the developer workstation running Ray locally, not a hardened production cluster.

Discovery

Credit is split between two researchers:

• Avi Lumelsky (@avilum), Oligo Security — originally theorized the fetch/User-Agent guard bypass; listed as finder.
• Jonathan Leitschuh (@JLLeitschuh), then at Socket — developed the DNS rebinding step and full proof-of-concept, and handled disclosure; listed as reporter.

Relationship to ShadowRay

This is related in class to ShadowRay, but is a distinct vulnerability — the two should not be conflated.

ShadowRay is the name Oligo Security gave in March 2024 to in-the-wild exploitation of CVE-2023-48022, Ray's unauthenticated job submission issue. Anyscale disputed that CVE on the grounds that Ray is documented as requiring a trusted network. Thousands of exposed Ray servers were nevertheless compromised for cryptomining, secret theft, and AI-workload data exfiltration. ShadowRay 2.0 (Oligo, late 2025) documented continued exploitation of the same CVE by the RondoDox, MooBot, and KmsdBot families, assembling a self-propagating botnet.

CVE-2025-62593 shares the same root condition — no authentication on /api/jobs and /api/job_agent/jobs/ — but targets a different attack surface. ShadowRay hits clusters directly exposed to the internet. CVE-2025-62593 reaches localhost-bound and internal instances that ShadowRay cannot touch, by pivoting through the developer's browser.

Exploitation Context

• CISA added this to the KEV catalog on 2026-08-18, roughly nine months after the patch shipped. KEV inclusion is itself CISA's assertion of confirmed in-the-wild exploitation.
• No public incident report, campaign writeup, or victim disclosure naming this CVE could be located. There is no published exploitation start date and no threat actor attribution specific to CVE-2025-62593 — the KEV listing is currently the sole public basis for asserting exploitation.
• Exposure counts do not meaningfully apply here. Figures circulating for "exposed Ray dashboards" relate to the ShadowRay internet-exposure problem and would understate the population at risk from this bug, which specifically reaches instances that are not exposed.
• A public proof-of-concept exists, published by Leitschuh as part of the disclosure.

Remediation

1. Upgrade Ray to 2.52.0 or later. This is the only complete fix. Rebuild any container images that bundle Ray rather than assuming the base image has been refreshed.
2. Do not rely on localhost binding as a control — defeating exactly that assumption is the point of this vulnerability.
3. Reduce browser-side risk. Developers running Ray locally in Firefox or Safari are the exposed population; Chrome is only incidentally protected. Avoid browsing untrusted sites while a Ray dashboard is running on the same machine.
4. Block DNS rebinding at the resolver. Configure the resolver to reject external DNS answers that resolve into RFC1918 or loopback space — dnsmasq --stop-dns-rebind, or the equivalent setting in Pi-hole, Unbound, or a corporate resolver.
5. Isolate the cluster. Never expose the Ray dashboard or Jobs API (default port 8265) to untrusted networks; front it with an authenticating reverse proxy and SSO, and firewall the dashboard port.
6. Review logs. Inspect Ray dashboard access logs for POST requests to /api/jobs and /api/job_agent/jobs/ carrying anomalous or absent User-Agent values or unexpected Origin/Referer headers, and for job submissions whose entrypoint invokes curl, wget, sh -c, or base64-encoded blobs. Cryptominer and credential-stealer behaviour of the kind documented in the ShadowRay campaigns is a reasonable secondary hunt.