Ray CVE-2025-62593: Critical Browser-Driven RCE via DNS Rebinding

Executive Summary

CVE-2025-62593 is a critical remote code execution vulnerability in Ray, a distributed computing framework widely used for Python and machine-learning workloads.

The attack combines DNS rebinding with a flawed User-Agent-based browser check. An attacker-controlled webpage can use the victim's browser to reach a locally running Ray Dashboard on port 8265, bypass the browser-request protection, and access the Jobs API without requiring Ray credentials.

By submitting a crafted Ray job, an attacker can potentially execute arbitrary commands with the privileges of the Ray process. This may expose source code, credentials, training data, model artifacts, cloud resources, and internal services, while also enabling resource abuse and lateral movement.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-62593 to the KEV catalog on 17 August 2026, citing active exploitation. Organizations should upgrade to Ray 2.52.0 or later, preferably 2.52.1, enable token authentication, restrict access to Ray management interfaces, and investigate affected systems for signs of compromise.

The vulnerability highlights a critical lesson: localhost is not automatically a trusted security boundary, especially for management interfaces capable of executing workloads.

What Is Ray?

Ray is an open-source distributed computing framework designed to scale Python applications and machine-learning workloads from a single developer machine to multi-node clusters. Originally developed at UC Berkeley and now maintained by the Ray project with Anyscale, Ray provides a distributed runtime that allows developers to execute Python workloads across CPUs, GPUs, and multiple machines without having to completely redesign their applications for distributed execution.

At its core, Ray provides three fundamental abstractions: tasks, actors, and objects. Tasks allow stateless Python functions to execute across the cluster, actors provide stateful worker processes, and objects allow data to be shared and accessed across distributed workers. Ray also handles resource scheduling, allowing workloads to request resources such as CPUs, GPUs, and memory and have them scheduled across available nodes.

This architecture makes Ray useful across a broad range of workloads. Its ecosystem includes Ray Data for distributed data processing, Ray Train for distributed model training, Ray Tune for hyperparameter optimization, RLlib for reinforcement learning, and Ray Serve for deploying and scaling machine-learning and Python applications. Ray can run locally, on cloud infrastructure, across physical or virtual machines, and on Kubernetes.

A basic deployment can start on a developer workstation with:pip install ray

A local Ray instance can then be initialized from Python or started as a Ray head node. In a cluster deployment, the head node coordinates the cluster while worker nodes provide the compute resources used to execute tasks and actors. This allows the same application to move from a local development environment to a distributed environment with substantially more CPU, GPU, memory, and storage capacity.

Ray Dashboard and Management APIs

Ray also provides a web-based Dashboard for monitoring applications, inspecting cluster resources, viewing jobs, and troubleshooting distributed workloads. A standard Ray deployment commonly exposes the Dashboard on TCP port 8265; for example, the official Kubernetes documentation uses port 8265 when forwarding access to a Ray head service.

The Dashboard is more than a passive monitoring interface. Ray exposes HTTP APIs that allow applications and operators to interact with the running cluster, including mechanisms for submitting and managing Ray jobs. This is an important security boundary because a Ray installation is effectively a distributed code-execution environment: workloads submitted to the cluster are intended to run as Python applications or tasks on Ray workers.

That distinction is important when analyzing CVE-2025-62593. The vulnerable component is not simply a conventional web application where an attacker gains access to a limited feature. Abuse of Ray's job-management functionality can cross directly into the distributed execution layer. If an attacker can successfully submit a malicious job, the resulting code executes within the security context of the Ray process and potentially gains access to the host, its files, credentials, network connectivity, and the other resources available to the cluster.

Why a Ray Compromise Is More Than a Single-App Breach

A Ray deployment is rarely an isolated application. In real environments, it can sit directly alongside sensitive development infrastructure and high-value machine-learning resources. A compromised Ray node may have access to training datasets, model checkpoints, source code, cloud credentials, internal services, GPUs, and other cluster nodes.

This creates several distinct security boundaries:

The security implications therefore extend well beyond the Ray process itself. Ray is specifically designed to execute distributed workloads, which means that compromising its control or job-submission interfaces can potentially provide an attacker with access to the same computing environment that developers and data scientists trust for production workloads.

This architecture is what makes CVE-2025-62593 particularly significant: the vulnerability combines a browser-based attack path with a service capable of launching distributed workloads, turning what may initially appear to be a local development interface into a potential path to arbitrary code execution on the underlying host.

Affected and Fixed Versions

The GitHub Security Advisory lists every Ray pip package version before 2.52.0 as affected. There is no partial patch; the fix is in 2.52.0 and was strengthened in 2.52.1.

Note on severity scoring: GitHub's CNA-assigned CVSS 4.0 score is 9.4 (Critical). NVD's CVSS 3.1 score is 8.8 (High). Both reflect network reachability, low attack complexity, and high impact on confidentiality, integrity, and availability. The difference is partly methodological — CVSS 4.0 treats browser-driven attacks more severely.

Root Cause: Code Injection Through Browser and DNS Rebinding

CVE-2025-62593 is the result of multiple security assumptions working together rather than a single coding error. In vulnerable Ray versions, the Dashboard relied on a User-Agent-based browser check to restrict browser-originated state-changing requests, while critical job-submission functionality remained accessible without authentication. DNS rebinding then provided a way for an attacker-controlled webpage to reach a Ray service running on the victim's localhost.

The attack depends on four conditions:

1. Unauthenticated job submission — Ray exposed the /api/jobs/ endpoint without requiring authentication in affected versions.
2. Weak browser detection — Ray attempted to block browser-originated POST and PUT requests by checking whether the User-Agent header started with Mozilla.
3. User-Agent manipulation — Firefox and Safari allow JavaScript to override the User-Agent header in the relevant fetch() request, allowing the browser check to be bypassed.
4. DNS rebinding — The attacker's domain can be made to resolve to 127.0.0.1:8265 or another reachable Ray instance, allowing the victim's browser to act as the bridge to the Ray Dashboard.

Once these conditions are combined, the attacker can reach the Jobs API and submit a Ray job containing an attacker-controlled entrypoint. Because Ray is designed to execute submitted workloads, this can ultimately result in arbitrary command execution with the privileges of the Ray process.

The Vulnerable Browser-Detection Logic

The vulnerable logic is located in ray/python/ray/dashboard/optional_utils.py, where Ray's is_browser_request function determines whether a request originated from a browser by checking whether the User-Agent header starts with Mozilla.

The security decision is therefore based on a client-controlled HTTP header:

# Conceptual reconstruction of the vulnerable guard
# NOT actual Ray source code

def is_browser_request(req):
    ua = req.headers.get("User-Agent", "")
    return ua.startswith("Mozilla")

def browsers_no_post_put_middleware(req, handler):
    if req.method in ("POST", "PUT") and is_browser_request(req):
        return Response("Browser requests not allowed", status=405)

    return handler(req)

The assumption behind this protection was that browser JavaScript could not modify the User-Agent header for fetch() or XHR requests. However, the relevant browser behavior differs across implementations: Firefox and Safari allow the User-Agent to be overridden in the attack scenario, while Chrome prevents this override.

An attacker can therefore send a request using a non-Mozilla value:

fetch("http://target/api/jobs/", {
    method: "POST",
    headers: {
        "User-Agent": "Other",
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        "entrypoint": "<test command>",
        "runtime_env": {}
    })
});

Ray receives the request with:User-Agent: Other

Because the value does not begin with Mozilla, is_browser_request() returns False. The request consequently bypasses the browser-request middleware and continues to the Jobs API.

The important security flaw is that User-Agent is request metadata controlled by the client and should not be used as an authentication or authorization boundary.

When combined with DNS rebinding, this bypass allows an attacker-controlled webpage to reach a Ray Dashboard running on the victim's localhost and submit a job through /api/jobs/. Because Ray is designed to execute submitted workloads, control of the job submission path can ultimately lead to arbitrary code execution with the privileges available to the Ray process.

Conceptual Vulnerable Application

The following example is a minimal Flask simulation of the vulnerable security pattern. It is not actual Ray source code and should not be interpreted as a direct reconstruction of Ray's implementation.

The simulation demonstrates the two conditions relevant to the attack:

1. A job-submission endpoint does not require authentication.
2. Browser requests are blocked using a User-Agent check that can be bypassed when the client can control that header.

# vulnerable_ray_app.py
# Conceptual lab simulation only — NOT actual Ray source code
from flask import Flask, request, jsonify
import subprocess
app = Flask(__name__)
def is_browser_request(req):
    # Vulnerable assumption:
    # browser requests always use a Mozilla-prefixed User-Agent.
    ua = req.headers.get("User-Agent", "")
    return ua.startswith("Mozilla")
@app.before_request
def guard_browser_post():
    if request.method in ("POST", "PUT") and is_browser_request(request):
        return "Browser requests not allowed", 405
@app.route("/api/jobs/", methods=["POST"])
def submit_job():
    # Conceptual vulnerable pattern:
    # an unauthenticated endpoint accepts an entrypoint
    # and passes it to a shell executor.
    body = request.get_json(force=True)
    entrypoint = body.get("entrypoint", "")
    subprocess.run(entrypoint, shell=True, check=False)
    return jsonify({
        "status": "submitted",
        "entrypoint": entrypoint
    })
if __name__ == "__main__":
    app.run(host="127.0.0.1", port=8265)

Why the Simulation Is Vulnerable

The browser protection makes a security decision based solely on the User-Agent header: return ua.startswith("Mozilla")

If the request contains a Mozilla-prefixed User-Agent, the middleware rejects the request. If the value is different, the request continues to /api/jobs/.

The second problem is that /api/jobs/ does not perform authentication before accepting the job definition. In this simplified simulation, the entrypoint is then passed to a shell executor.

This reproduces the security pattern behind the vulnerability without claiming that this Flask application is the actual Ray implementation.

Why This Vulnerability Is Critical

• No authentication: The attack does not require Ray credentials, API tokens, or VPN access to the vulnerable local service.
• Browser-based entry point: A victim only needs to visit an attacker-controlled webpage while using a browser affected by the User-Agent bypass and running Ray locally.
• DNS rebinding: DNS rebinding allows the attacker's webpage to reach a Ray Dashboard bound to localhost and can potentially extend the attack to reachable internal Ray instances.
• Code execution: Successful job submission can reach Ray's workload-execution layer, resulting in arbitrary command execution with the privileges of the Ray process.
• High-value target: Ray environments may have access to source code, credentials, datasets, model artifacts, cloud resources, and significant CPU/GPU capacity.
• Potential lateral movement: A compromised Ray host can provide a foothold for discovering and accessing internal services and additional Ray infrastructure.
• Active exploitation: CISA added CVE-2025-62593 to the KEV catalog citing active exploitation. BitSight also reported RondoDox activity attempting to exploit the vulnerability before public disclosure, although the specific observed implementation did not successfully bypass Ray's browser check

Attack Chain: From Malicious Web Page to Developer-Host RCE

CVE-2025-62593 is not a single-step exploit. The attack combines several weaknesses across the browser, DNS resolution, Ray's Dashboard, and the Jobs API. An attacker can use a malicious webpage to reach a Ray service running on the victim's machine, bypass the Dashboard's browser-request protection, submit a Ray job, and ultimately achieve code execution with the privileges available to the Ray process.

The attack consists of six stages: reconnaissance, DNS rebinding, User-Agent bypass, job submission, remote code execution, and post-exploitation.

1. Reconnaissance

The attack begins by identifying a potential Ray environment and determining whether the victim's browser is suitable for the attack path.

Ray commonly exposes its Dashboard on TCP port 8265. In local deployments, the Dashboard may be available at 127.0.0.1:8265.

The attacker does not need direct network access to the local Ray service. Instead, the objective is to determine whether the victim's browser can reach the Dashboard and whether the environment matches the vulnerable configuration.

Potential indicators include:

• Suspicious landing pages targeting developers or ML engineers.
• Browser activity involving unusual domains.
• DNS requests involving short-TTL domains.
• Unexpected access to Ray Dashboard services.

2. DNS Rebinding

The attacker then uses DNS rebinding to make the victim's browser communicate with the local Ray Dashboard.

Initially, the attacker-controlled domain resolves to attacker infrastructure. After the malicious page is loaded, the domain can resolve to a local or private address associated with Ray, such as 127.0.0.1:8265.

The attacker therefore does not need to connect directly to the victim's loopback interface. The victim's browser performs the connection, acting as the bridge between the malicious webpage and the local Ray service.

This is why binding Ray to localhost alone does not necessarily prevent the browser-based attack path.

Potential indicators include:

• Extremely short DNS TTLs.
• Rapid A-record changes.
• Domains resolving between external and private or loopback addresses.
• Browser activity followed by connections to local services.

3. User-Agent Bypass

Once the browser can reach Ray, the attacker needs to bypass its browser-request protection.

The vulnerable logic uses the User-Agent header to identify browser-originated requests. Requests with a User-Agent beginning with Mozilla are treated as browser requests and rejected for sensitive POST and PUT operations.

The problem is that User-Agent is client-controlled metadata, not a reliable security boundary.

In the documented attack path, Firefox and Safari allow the relevant JavaScript request to provide a different User-Agent value. A value such as Other therefore avoids the vulnerable Mozilla check.

A conceptual request is:

fetch("http://target/api/jobs/", {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
        "User-Agent": "Other"
    },
    body: JSON.stringify({
        "entrypoint": "<safe test command>",
        "runtime_env": {}
    })
});

The key security issue is that client-controlled headers should never be used as an authentication or authorization boundary.

Relevant indicators include:

• POST/PUT requests to Ray endpoints with unusual User-Agent values.
• Browser-originated requests using non-browser User-Agent strings.
• Suspicious Origin or Referer values associated with Ray API requests.

4. Job Submission

After bypassing the browser-request protection, the attacker reaches the Ray HTTP interface and targets the Jobs API.

The relevant endpoint is:/api/jobs/

The Jobs API is designed to submit and manage Ray workloads. A job submission includes an entrypoint and can also specify a runtime environment.

A representative request is:

POST /api/jobs/ HTTP/1.1
Host: 127.0.0.1:8265
Origin: https://attacker.example
User-Agent: Other
Content-Type: application/json

{
  "entrypoint": "<attacker-controlled command>",
  "runtime_env": {}
}

For a safe laboratory demonstration:

{
  "entrypoint": "echo RAY_CVE_TEST",
  "runtime_env": {}
}

At this stage, the attack has moved beyond browser request manipulation. The attacker has reached an interface capable of submitting workloads to the Ray execution environment.

Relevant indicators include:

• Unexpected POST /api/jobs/ requests.
• Unauthorized or unusual job submissions.
• Suspicious entrypoint values.
• Ray jobs occurring immediately after suspicious browser activity.

5. Remote Code Execution

The next stage is remote code execution.

Ray is designed to execute submitted workloads. Once the attacker gains control over the job-submission path, the attack can transition from manipulating an HTTP request to executing code within the Ray runtime.

The execution context depends on the deployment. On a developer workstation, Ray may run under the developer's account. In a cluster, execution may occur through Ray workers or another configured execution environment.

Successful exploitation may therefore provide access to resources available to the Ray process, including:

• Source code.
• Environment variables and configuration.
• Credentials and cloud tokens.
• Databases.
• Training datasets.
• Model artifacts.
• Internal services.

This is the point at which CVE-2025-62593 becomes an RCE vulnerability rather than simply a browser-request bypass.

Relevant indicators include:

• Ray workers spawning unexpected shells or interpreters.
• Unusual child processes.
• Unexpected binaries or scripts.
• Suspicious outbound connections.
• Abnormal file access by Ray processes.

6. Post-Exploitation

Code execution on the Ray host may be only the beginning of the attack.

After compromising the environment, an attacker may attempt to access credentials, discover internal services, or move toward additional infrastructure. Depending on the deployment and privileges, this may include:

• Cloud credentials and API tokens.
• SSH keys and application secrets.
• Internal APIs and databases.
• Additional Ray clusters.
• Development infrastructure.
• Cloud resources.

Ray environments also provide substantial CPU and GPU resources, which can be abused for unauthorized computation such as cryptocurrency mining.

An attacker may additionally attempt to establish persistence or use the compromised Ray host as a foothold for lateral movement.

Relevant indicators include:

• Credential-access activity.
• Internal network scanning.
• Unexpected connections to other Ray clusters.
• Cryptocurrency-mining traffic.
• Persistence mechanisms.
• Unusual CPU/GPU utilization.

Representative HTTP Exchange

The following exchange is a conceptual representation of the request generated after DNS rebinding redirects the browser toward a locally running Ray Dashboard. The hostname can remain attacker-controlled while the connection is ultimately resolved to the victim's local Ray service.

POST /api/jobs/ HTTP/1.1
Host: attacker.com
Origin: http://attacker.com
User-Agent: Other
Content-Type: application/json

{
  "entrypoint": "<attacker-controlled command>",
  "runtime_env": {}
}

A successful submission may return a response similar to:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "submitted",
  "entrypoint": "<attacker-controlled command>"
}

For a safe laboratory demonstration, the entrypoint can contain a harmless command:

{
  "entrypoint": "echo RAY_CVE_TEST",
  "runtime_env": {}
}

The important elements of the request are:

• POST /api/jobs/ — targets Ray's job-submission interface.
• Host / Origin — remain associated with the attacker-controlled domain.
• User-Agent: Other — avoids the vulnerable Mozilla prefix check.
• entrypoint — represents the attacker-controlled workload submitted to Ray.
• runtime_env — can provide additional runtime configuration for the submitted job.

The security significance is that the request crosses from a browser-controlled context into Ray's workload-execution interface. If the job is accepted, Ray processes the submitted workload according to its normal execution model.

For a public blog, I would avoid including a curl | bash, reverse-shell, or cryptominer payload. The harmless echo RAY_CVE_TEST example is sufficient to demonstrate the vulnerable request flow without turning the section into a ready-to-use exploitation payload.

Lab Setup and Exploitation

The lab below provides a safe, self-contained simulation of the attack pattern. It is not actual Ray source code and should not be considered a direct reproduction of Ray's implementation.

The simulation demonstrates the confused-deputy pattern: a Flask application implements a Mozilla-only browser guard and an unauthenticated job endpoint, while a separate HTML page attempts to bypass the guard using a modified User-Agent.

The real attack relies on DNS rebinding. To keep the lab portable and deterministic, the simulation uses localhost directly instead of reproducing the external DNS infrastructure.

Lab Components

• vulnerable_ray_app.py — Conceptual Ray Dashboard simulation containing the vulnerable browser-request check and job-submission endpoint.
• exploit.html — Demonstration webpage that sends a browser-originated request with a non-Mozilla User-Agent.
• serve_exploit.py — Minimal HTTP server used to host the demonstration page.
• run_lab_and_screenshot.py — Optional automation script used to start the lab, launch the browser, trigger the request, and capture the results.

Lab Evidence

The screenshots below were captured from an automated run of the lab. They show the dashboard fingerprint check, the exploit page submitting the malicious job, the server accepting the POST with the forged User-Agent, and the proof-of-compromise marker file being created.

Screenshot 1 — Conceptual Ray dashboard root page

Screenshot 2 — Exploit page before triggering the request

Screenshot 3 — Exploit result showing HTTP 200 and submitted entrypoint

Screenshot 4 — Proof-of-compromise check confirming the marker file exists

Screenshot 5 — Server log showing the forged-User-Agent POST reaching /api/jobs/

Security Impact

CVE-2025-62593 can turn a malicious webpage visit into code execution on a Ray host. The resulting impact depends on the privileges of the Ray process and the resources accessible from the compromised environment.

1. Remote Code Execution

• Execute arbitrary commands on the Ray host.
• Gain access with the privileges of the Ray process.
• Install malicious tools or scripts.

2. Data and Credential Theft

• Source code and configuration files.
• Cloud credentials and API keys.
• SSH keys and application secrets.
• Training data and model artifacts.

3. Resource Abuse

• Cryptocurrency mining.
• Unauthorized CPU/GPU workloads.
• Resource exhaustion.
• Increased cloud infrastructure costs.

4. Lateral Movement

• Discover internal services and databases.
• Access cloud and private infrastructure.
• Reach additional Ray clusters.
• Use the compromised host as an internal foothold.

5. ML Asset Exposure

• Steal model weights and checkpoints.
• Access training datasets.
• Modify ML workloads or artifacts.
• Expose proprietary research.

6. Persistence and Supply-Chain Risk

• Modify dependencies or runtime environments.
• Introduce malicious workloads or packages.
• Maintain access to the compromised environment.
• Potentially affect other connected workloads.

7. Developer Workstation Compromise

• Access development repositories.
• Read local environment and configuration files.
• Abuse credentials available to the developer.
• Pivot into the broader development environment.

Overall Impact

The combination of browser-based access, weak browser-request validation, and Ray's workload-execution capabilities can turn a malicious webpage into a foothold on a developer workstation or Ray cluster. From there, attackers may steal credentials and ML assets, abuse compute resources, or move deeper into connected infrastructure.

Fix and Mitigation

The primary remediation for CVE-2025-62593 is to upgrade Ray to version 2.52.0 or later. Ray 2.52.0 introduced the browser-request hardening associated with the vulnerability, while Ray 2.52.1 added broader browser-header testing and is therefore the preferred version for defense-in-depth.

Ray 2.52.0 also introduced token authentication for the Dashboard, CLI, API clients, and internal services. Because authentication is not enabled by default, administrators should explicitly enable it rather than relying solely on the browser-request protections.

Immediate Actions

1. Upgrade Ray immediately
   • Upgrade every Ray installation to 2.52.0 or later.
   • Prefer 2.52.1 where possible.
   • Include developer workstations, CI/CD environments, research systems, Kubernetes deployments, and production clusters in the inventory.
2. Enable Ray token authentication
   • Enable authentication for the Ray Dashboard and API interfaces.
   • Apply the same authentication requirements to CLI clients and internal services.
   • Do not rely on User-Agent or other client-controlled headers as an access-control mechanism.
3. Restrict Ray network exposure
   • Ensure port 8265 is not exposed directly to the Internet.
   • Restrict access to Ray management interfaces using firewalls, security groups, network ACLs, or VPN controls.
   • Bind Ray services to explicit interfaces rather than unnecessarily exposing them on all network interfaces.
4. Review potentially exposed credentials
   • Identify credentials accessible from vulnerable Ray hosts.
   • Rotate cloud credentials, API keys, database passwords, SSH keys, and other sensitive secrets where exposure cannot be ruled out.
   • Review cloud audit logs for suspicious use of credentials associated with affected systems.
5. Hunt for exploitation
   • Review historical Ray Dashboard and Jobs API activity.
   • Search for unexpected requests to /api/jobs/.
   • Investigate unusual User-Agent values associated with Ray POST/PUT requests.
   • Review DNS telemetry for suspicious short-TTL or rapidly changing domains.
   • Check EDR telemetry for shells, interpreters, or unfamiliar binaries spawned by Ray processes.
6. Inspect running workloads
   • Review active and recently completed Ray jobs.
   • Look for unexpected job submissions, unfamiliar entrypoints, or unauthorized runtime environments.
   • Investigate unexplained CPU/GPU consumption and unusual outbound network connections.

Conclusion

CVE-2025-62593 shows how multiple seemingly minor security weaknesses can combine into a critical attack path. By combining DNS rebinding, weak User-Agent-based browser protection, and unauthenticated job submission, an attacker-controlled webpage can potentially reach a local Ray service and achieve arbitrary code execution.

The impact can extend well beyond the Ray process. A compromised developer workstation or Ray node may expose source code, credentials, training data, model artifacts, cloud resources, and internal services, while available CPU and GPU resources can also be abused.

Organizations running Ray should treat the vulnerability as a high-priority security issue. They should upgrade to Ray 2.52.0 or later, preferably 2.52.1, enable token authentication, restrict access to Ray management interfaces, and investigate vulnerable systems for signs of compromise.

The broader lesson is clear: localhost is not automatically a trusted security boundary. Management interfaces capable of executing workloads should be protected with strong authentication and network controls rather than relying on browser behavior or client-controlled headers.