Skip to main content
CVE-2025-62593 Critical Patch Available

CVE-2025-62593: Ray — Browser CSRF Chains to Code Injection RCE

CVE Details

CVE ID CVE-2025-62593
CVSS Score 9.4
Severity Critical
Vendor Ray-Project
Product Ray
Patch Status Available
Published August 17, 2026
EPSS Score 16.9%
CISA Patch Deadline ⚠ August 20, 2026 Federal deadline passed

Background

Ray is the open-source distributed computing framework widely used for ML training, model serving, and large-scale Python workloads. Its Dashboard exposes a REST API, used by both the web UI and programmatic clients, to manage jobs, actors, and cluster resources — including the ability to submit a job that executes arbitrary Python code on the cluster. That capability is by design in a trusted environment; the problem is what stands between it and the public internet.

CVE-2025-62593 chains a cross-site request forgery weakness (CWE-352) with code injection (CWE-94) in Ray’s Dashboard API, enabling a malicious website to submit arbitrary Python jobs to a developer’s local Ray cluster when the developer simply browses a crafted page in Firefox or Safari. CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on August 17, 2026, with a remediation deadline of August 20 for federal agencies under BOD 26-04 — a three-day window that signals confirmed active exploitation rather than theoretical risk.

Technical Mechanism

The core capability — submitting a job that executes arbitrary Python code — is by design. The vulnerability is that this API did not require credentials or carry CSRF protections sufficient to prevent cross-origin requests.

The CSRF component (CWE-352): CSRF defenses rely on either same-site cookie attributes, CSRF tokens embedded in requests, or CORS policies that restrict which origins can send credentialed requests. Ray’s Dashboard API historically had minimal authentication, which predates this specific CVE and has been an ongoing class of concern since the ShadowRay campaign documented in 2024. For CVE-2025-62593, the CSRF channel is enabled specifically in Firefox and Safari due to differing handling of cross-origin requests to local addresses (127.0.0.1 and localhost) compared to Chrome.

Chrome has enforced stricter handling of requests from public network origins to private (RFC 1918 and localhost) addresses via the Private Network Access (PNA) specification, and also applies SameSite=Lax as the default cookie attribute since 2020. Firefox and Safari have lagged on PNA implementation. A malicious page served from the public internet can cause Firefox or Safari to send requests to http://127.0.0.1:8265 — the Ray Dashboard — without triggering the cross-origin protections that would block this on Chrome. Ray’s own defence against this relied on checking that the User-Agent header starts with “Mozilla”, which every browser sends and is trivial to satisfy.

The code injection component (CWE-94): Ray’s Job Submission API (/api/jobs/) accepts a job specification containing the Python entrypoint and runtime environment. Submitting a job causes Ray to execute the specified Python code on the cluster. No authentication is required in unpatched versions. A CSRF-delivered POST request to this endpoint, containing a malicious job spec, results in arbitrary Python execution on the Ray cluster with the process credentials of the Ray worker.

Attack scenario:

  1. Developer runs Ray locally or on a network-accessible host with the Dashboard on port 8265.
  2. Developer opens Firefox or Safari and visits a malicious website.
  3. The malicious page’s JavaScript makes a cross-origin POST to http://127.0.0.1:8265/api/jobs/ with a crafted job payload.
  4. Ray accepts the job submission, spawns a worker, and executes the attacker-controlled Python code.
  5. The attacker achieves code execution on the Ray host with the permissions of the Ray process.

The attack does not require the developer to click anything beyond loading the page. No credentials are stolen in the attack; the CSRF channel is the sole mechanism.

Real-World Exploitation Evidence

CISA’s addition to the KEV catalog confirms that exploitation has been observed. The exact threat actor attribution or campaign details have not been publicly disclosed as of this writing, but the context is informative.

Ray has been a persistent target since the ShadowRay campaign (documented by Oligo Security in early 2024), which identified over 100 Ray deployments exposed directly to the public internet with no authentication, allowing attackers to mine cryptocurrency, deploy reverse shells, and exfiltrate ML model weights and cloud credentials from the cluster’s environment variables. CVE-2025-62593 extends the attack surface from internet-exposed clusters to locally running developer instances accessible only from the developer’s own machine — a significantly broader population of targets.

Impact Assessment

ML and data engineering teams are high-value targets for several reasons: their development environments commonly contain cloud provider API keys (AWS, GCP, Azure), Hugging Face tokens, database credentials, and access to proprietary training data and model weights. Compromise of a Ray worker achieves access to everything in the process environment and the local filesystem accessible to it.

  • Exfiltration of cloud credentials and API keys from the Ray process environment
  • Access to proprietary training data and model weights on compromised clusters
  • Lateral movement from a compromised Ray worker into connected infrastructure
  • Denial of service or resource hijacking (cryptomining) on the affected cluster
  • Elevated risk for any developer running Ray locally in Firefox or Safari, regardless of network exposure

Affected Versions

ProductAffected VersionsFixed Version
Ray (Ray-Project)prior to 2.52.02.52.0

Ray’s Dashboard runs on port 8265 by default. Deployments that start Ray with ray start --head or ray.init() in development mode, do not bind the Dashboard to localhost only, or do not sit behind a reverse proxy with appropriate CORS configuration, are all within scope.

Remediation Steps

  1. Apply the upstream fix. Update Ray to version 2.52.0 or later, which includes commit 70e7c72780bdec075dba6cad1afe0832772bfe09 adding CSRF protections to the Dashboard API endpoints involved in job submission. Refer to GitHub security advisory GHSA-q279-jhrf-cc6v for details.

  2. Bind the Dashboard to localhost only if patching is not immediately possible: ray start --head --dashboard-host=127.0.0.1.

  3. Firewall port 8265 to block inbound connections from any interface except loopback.

  4. Avoid Firefox or Safari while the Ray Dashboard is running, or isolate browsing to a separate browser profile/machine, until patched.

  5. Add a reverse proxy with authentication in front of the Dashboard if network access is genuinely required, and enable Ray’s built-in authentication features available in recent versions.

Detection Guidance

Log sources: Ray logs job submission events with the submitting origin and job parameters. Enable verbose logging (--logging-level=DEBUG) if investigating suspected exploitation. Look for jobs submitted during periods when no legitimate workflow was running.

What to look for:

  • Unexpected job submissions to the Ray API, particularly with entrypoints referencing network utilities (nc, curl, wget), shell commands, or unusual Python modules not part of your normal workflows.
  • New processes spawned by the Ray worker with unexpected parent-child relationships (a ray::IDLE worker spawning a shell or network tool is anomalous).
  • Outbound network connections from Ray worker processes to unexpected external addresses; Ray workers typically communicate within the cluster, not to arbitrary external IPs.
  • Presence of credential harvesting artifacts: files named .aws, *.pem, or unusual base64-encoded data written to the Ray temp directory (/tmp/ray).

Network-level detection: Monitor for POST requests to /api/jobs/ on port 8265 originating from sources that are not your known automation or CI/CD systems. In environments where Ray should not receive job submissions from browsers at all, any browser-origin User-Agent making job API calls is suspicious.

Host-based indicators: The Ray worker process name is ray::IDLE or ray::your_task_name. Unusual child processes (bash, sh, python with suspicious arguments) launched by Ray worker processes warrant investigation.

Timeline

DateEvent
2026-xx-xxVulnerability reported and fixed upstream in Ray 2.52.0
2026-08-17CISA adds CVE-2025-62593 to the Known Exploited Vulnerabilities catalog
2026-08-20CISA BOD 26-04 mandatory remediation deadline for federal agencies

References