CVE-2025-62593 and the CISA KEV listing: what Ray users need to know

In short: CVE-2025-62593 affects Ray versions before 2.52.0 and was fixed in 2.52.0, released November 26, 2025. If you are running 2.52.0 or later, you are not affected. If you are on an earlier version, please upgrade and enable token authentication. To check what Ray version you have, run ray --version, or pip show ray. CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 17, 2026, with an August 20 remediation deadline for federal civilian agencies.

On August 17, 2026, CISA added CVE-2025-62593 to its KEV catalog under Binding Operational Directive 26-04, which allows a compressed three-day remediation window for vulnerabilities the agency considers especially risky.

The listing is accurate and if teams are still running a version of Ray below 2.52.0, we recommend upgrading Ray.

CVE-2025-62593 was reported through coordinated disclosure, patched, and published in GHSA-q279-jhrf-cc6v on November 26, 2025.

Every Ray release since then contains the fix. What changed this week is CISA's assessment of exploitation activity, rather than the vulnerability itself or the exposure of anyone already on a current release. A KEV listing speaks to attacker behavior against unpatched systems, and it remains an important signal for teams that have not upgraded yet.

If you are running an earlier version, upgrading is the entire remediation.

LinkDescription of the vulnerability

Ray's dashboard and job submission API deliberately execute code that is submitted to them. That is what Ray is for. To keep a random web page from reaching a Ray instance running on a developer's laptop, Ray checked whether the incoming request's User-Agent header began with Mozilla and rejected it if so.

That check turned out to be bypassable. The Fetch specification permits scripts to set User-Agent, and Firefox and Safari implement it faithfully. Chrome does not, and was therefore not a viable attack path.

On its own, a bypassable header check is not enough to reach a local Ray instance, because the browser's same-origin policy still applies. The researchers chained it with DNS rebinding, which makes the browser treat an attacker-controlled hostname and the developer's localhost:8265 as the same origin. The result is that a developer running Ray locally who visits a malicious page, or is served a malicious ad, can have shell commands executed on their machine with no further interaction.

Ray 2.52.0 replaced the heuristic with proper browser-origin controls.

LinkEnabling token authentication for your Ray 

Ray 2.52.0 introduced token-based authentication for the dashboard, job submission, and Ray Client. It is currently opt-in.

Token auth is a direct and effective control against this attack class. A cross-origin script cannot read the token and cannot guess it, so a rebinding attack that reaches the endpoint still fails at authentication. It is defense in depth that does not depend on the browser's same-origin behavior being correct, on a header check holding, or on whether a given browser vendor has shipped local network access restrictions yet.

We recommend enabling it. Concretely:

1. Upgrade to a recent Ray release. 2.52.0 is the minimum for CVE-2025-62593. Later is better, and there have been additional browser-boundary hardening fixes since.

2. Enable token authentication in development environments as well as production. Local development is where this vulnerability was exploitable.

3. Keep the trusted perimeter intact. Ray expects to run inside a defined network boundary that you control and that only carries traffic you intend. Every host and service inside that boundary is, in effect, authorized to submit work to the cluster, so the boundary should be drawn as tightly as the workload allows. Isolation and authentication are complementary controls, not alternatives to each other.

4. Do not expose the dashboard beyond that perimeter. Check for --dashboard-host=0.0.0.0 in cluster configs, container images, and Helm charts where it is not required. This applies to local development just as much as to production: ray start --head on a laptop, a long-running dev cluster on a workstation, or a Ray instance inside a development container or VM should bind to loopback unless something genuinely needs to reach it. A dashboard bound to all interfaces on a developer machine is reachable from anything else on the office or home network, which is the exact position CVE-2025-62593 was exploited from.

5. Check the places you are not looking. This includes pinned versions in lockfiles, base images, CI runner images, and long-lived notebook environments.

We are actively working toward making token authentication the default rather than an opt-in, and we will have more to say about that timeline.

LinkOn the disclosure record

This vulnerability was found by external researchers, reported privately, fixed, and published with a full technical writeup and a proof of concept. 

We are grateful to everyone who does security work. The researchers who report to Ray make it safer for everyone running it. Ray's security advisories are public at github.com/ray-project/ray/security/advisories.

If you have found a security issue in Ray, please report it through the project's security policy rather than filing a public issue. We would rather hear it early.