CVE-2025-62593: Ray Code Injection Vulnerability Under Active Exploitation — CISA KEV Detection and Remediation Guide

On August 18, 2026, CISA formally added CVE-2025-62593 — a code injection vulnerability in the Ray-Project Ray distributed computing framework — to the Known Exploited Vulnerabilities (KEV) catalog. This is not a theoretical risk. KEV inclusion means CISA has confirmed active exploitation in the wild, and every organization running Ray clusters — particularly those exposing the Ray Dashboard or Jobs API to a network — should treat this as an incident-level priority, not a backlog item.

Ray has become the de facto orchestration layer for machine learning training, distributed Python workloads, and AI pipeline infrastructure. It runs in data science environments, MLOps platforms, Kubernetes clusters, and cloud-native AI services. That ubiquity is precisely the problem: Ray was architected for trusted internal networks, and its remote interfaces have historically shipped without authentication by default. CVE-2025-62593 weaponizes that design assumption.

Federal Civilian Executive Branch (FCEB) agencies are bound by CISA Binding Operational Directive (BOD) 26-04 — Prioritizing Security Updates Based on Risk, which mandates remediation of KEV-listed vulnerabilities within defined windows, alongside CISA's Forensics Triage Requirements for affected systems. Private-sector organizations should treat the KEV due date as a de facto industry deadline — attackers are already operationalizing this bug, and your timeline is theirs.

Technical Analysis

Affected Product and Exposure Surface

CVE-2025-62593 affects the Ray-Project Ray framework — the open-source distributed execution engine used for parallel Python workloads, reinforcement learning, hyperparameter tuning, and LLM training/serving stacks (often underneath frameworks like vLLM, Anyscale deployments, and custom MLOps platforms).

The vulnerability is a code injection flaw in Ray's remotely reachable components — most critically the Ray Dashboard (default TCP/8265) and its associated Jobs submission API, which accepts and executes arbitrary Python code on cluster nodes. Key defensive facts every responder should internalize:

• No authentication by default. The Ray Dashboard and Jobs API were designed for trusted networks. If port 8265 (or the GCS/head-node ports) is reachable, an attacker can submit jobs that execute with the privileges of the Ray process — frequently root inside containers.
• Attack surface reachable from browsers. CISA's advisory notes exploitation paths accessible via Firefox and Safari, meaning the injection can be triggered through browser-delivered requests against developer workstations running local Ray instances, or via cross-origin-style request delivery to dashboards reachable on internal networks. Developers using Ray "as a development tool" on laptops are explicitly in scope — this is not only a datacenter problem.
• Unauthenticated remote code execution. Successful exploitation yields command execution on the head node and, because Ray propagates tasks to workers, likely cluster-wide compromise in a single shot.

Exploitation Mechanics (Defender's View)

From an attack-chain perspective, exploitation follows a predictable pattern:

1. Discovery — attacker scans for or stumbles onto a reachable Ray Dashboard (TCP 8265) or Jobs API endpoint. Shodan/Censys exposure of Ray instances has been a known problem for years; internal pivoting after any initial foothold is equally viable.
2. Job submission — an unauthenticated HTTP POST to the Jobs API submits a "job" containing attacker-controlled Python. The code injection flaw allows execution outside intended constraints.
3. Execution — the Ray head node executes the payload. Typical post-exploitation: the Ray Python process spawns bash/sh/curl/wget, pulls a second-stage payload (miner, RAT, or cloud-credential harvester), and establishes outbound C2.
4. Lateral expansion — Ray's architecture means worker nodes trust the head node. Compromise of the head equals compromise of every connected worker, often including GPU-rich nodes with access to training data, model weights, and cloud IAM instance metadata credentials.

The blast radius here is severe: ML clusters routinely hold proprietary training data, model intellectual property, and over-privileged cloud roles. A Ray compromise is rarely just a Ray compromise — it is a foothold into your highest-value compute environment.

Exploitation Status

• CISA KEV: Listed 2026-08-18 — confirmed active exploitation in the wild.
• Required action (per CISA): Apply vendor mitigations; comply with BOD 26-04 risk-prioritization guidance and CISA Forensics Triage Requirements; follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable.
• Verification: CISA KEV Catalog — CVE-2025-62593

If you cannot confirm your Ray exposure status within 24 hours, assume you are exposed. ML infrastructure is chronically under-inventoried.

Detection & Response

This is an active-exploitation technical threat. The detections below target the highest-fidelity observable: the Ray runtime spawning shells, downloaders, or scripting interpreters — behavior with virtually no legitimate justification in production clusters — plus network exposure of the dashboard itself.

Sigma Rules

---
title: Ray Process Spawning Shell or Downloader (CVE-2025-62593 Post-Exploitation)
id: 3f8a1c94-62d7-4b51-9e0a-7c2d5f1a8b34
status: experimental
description: Detects Ray runtime, dashboard, or raylet processes spawning shells, download utilities, or interpreters — consistent with unauthenticated job-submission exploitation of Ray (CVE-2025-62593) followed by second-stage payload retrieval.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-62593
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/19
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.006
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'ray::'
      - '/ray/dashboard'
      - 'raylet'
      - 'gcs_server'
  selection_child:
    CommandLine|contains:
      - '/bin/bash'
      - '/bin/sh'
      - 'curl '
      - 'wget '
      - 'python -c'
      - 'base64 -d'
      - 'chmod +x'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Ray workloads that invoke subprocesses — baseline your cluster's normal job patterns before deploying at high level
level: high
---
title: Network Exposure of Ray Dashboard Port 8265 to External Sources
id: 9b2e7d41-5f3a-4c68-a1d9-4e6f8b2c7a15
status: experimental
description: Detects inbound connections to the Ray Dashboard default port (8265) from non-internal source addresses. The dashboard/Jobs API is unauthenticated by default and is the primary exploitation vector for CVE-2025-62593.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-62593
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/19
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort:
      - 8265
      - 10001
      - 6379
  filter_internal:
    SourceIp|startswith:
      - '10.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.2'
      - '192.168.'
      - '127.'
  condition: selection and not filter_internal
falsepositives:
  - Misconfigured load balancers or health-check infrastructure outside RFC1918 ranges
level: high
---
title: Outbound C2 or Payload Staging from Ray Cluster Nodes
id: 5c1d9f27-8e4b-4a36-b7c2-9d3a6e1f5b08
status: experimental
description: Detects Ray cluster worker/head node processes initiating outbound connections to rare external destinations — consistent with second-stage payload download or C2 establishment following Ray Jobs API exploitation.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-62593
  - https://attack.mitre.org/techniques/T1071/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/19
tags:
  - attack.command_and_control
  - attack.t1071.001
  - attack.t1105
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    Image|contains:
      - 'curl'
      - 'wget'
      - 'nc'
      - 'ncat'
    Initiated: 'true'
  filter_user:
    User|contains:
      - 'root'
  filter_context:
    ParentImage|contains:
      - 'python'
      - 'ray'
  condition: selection and filter_user and filter_context
falsepositives:
  - Data pipelines legitimately downloading model artifacts — tune against known artifact repositories (e.g., internal S3, Hugging Face)
level: medium

KQL — Microsoft Sentinel / Defender

Ray clusters are predominantly Linux, so the primary hunt below runs against Syslog and CommonSecurityLog (CEF) ingestion, with a DeviceProcessEvents variant for developer workstations onboarded to Defender for Endpoint (relevant given the Firefox/Safari delivery path against developers running local Ray instances).

// Hunt 1: Ray-related processes spawning shells or downloaders (Linux via Syslog process events)
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName in~ ("bash", "sh", "curl", "wget", "nc", "ncat", "python", "python3")
| where Computer has_any ("ray", "ml", "gpu", "train", "head", "worker")  // tune to your cluster naming
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Count = count()
    by Computer, ProcessName, SyslogMessage, HostIP
| order by Count asc  // rare executions on cluster nodes are the anomaly
| project FirstSeen, LastSeen, Count, Computer, ProcessName, SyslogMessage, HostIP;

// Hunt 2: External connections to Ray Dashboard port 8265 via CEF/firewall logs
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DestinationPort in (8265, 10001, 6379)
| where SourceIP !startswith "10." and SourceIP !startswith "192.168." and SourceIP !startswith "172."
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by ConnectionCount desc;

// Hunt 3: Developer workstations — browsers or local Ray spawning unexpected child processes
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("firefox", "safari", "ray", "python", "raylet")
| where FileName in~ ("bash", "sh", "zsh", "curl", "wget", "powershell.exe", "cmd.exe")
    or ProcessCommandLine has_any ("curl ", "wget ", "base64 -d", "/dev/tcp/")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, FileName, ProcessCommandLine, RemoteIP, RemoteUrl
| order by TimeGenerated desc;

The workstation hunt (Hunt 3) matters because CISA specifically calls out developer exposure via Firefox and Safari — a developer running a local ray start or ray.init() with the dashboard bound to a non-loopback interface is a valid target through browser-delivered requests.

Velociraptor VQL

Deploy this as a hunt across suspected Ray head nodes and developer endpoints. It enumerates live Ray processes and their network bindings to confirm dashboard exposure and catch active shell spawns.

-- Identify Ray processes, their command lines, and listening sockets on endpoints
LET ray_procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)ray|gcs_server|dashboard'
   OR Exe =~ '(?i)raylet|gcs_server'

SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM ray_procs

-- Separately: check for Ray dashboard/GCS ports listening on non-loopback interfaces
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, State
FROM netstat()
WHERE LocalPort in (8265, 10001, 6379, 8080)
   AND NOT LocalAddress =~ '^(127\.|::1|\[::1\])'

-- Catch children of Ray processes (post-exploitation shells/downloaders)
SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM pslist()
               WHERE CommandLine =~ '(?i)ray::|raylet|dashboard')
   AND Name =~ '(?i)bash|sh|zsh|curl|wget|nc|ncat|socat|perl|python'

Remediation Script

The Bash script below performs three functions on a suspected Ray node: (1) detect whether the dashboard is exposed beyond loopback, (2) identify suspicious child processes and recently dropped executables consistent with exploitation, and (3) apply emergency containment — binding Ray to localhost and blocking dashboard ports via the local firewall — while you execute a full patch or shutdown.

#!/bin/bash
# CVE-2025-62593 Ray Emergency Triage & Containment
# Run as root on any suspected Ray head/worker node BEFORE patching.

echo "=== [1] Checking Ray dashboard exposure ==="
EXPOSED=$(ss -tlnp 2>/dev/null | grep -E ':(8265|10001|6379)\b' | grep -vE '127\.0\.0\.1|\[::1\]')
if [ -n "$EXPOSED" ]; then
    echo "[!] CRITICAL: Ray services listening on non-loopback interfaces:"
    echo "$EXPOSED"
else
    echo "[+] No externally bound Ray services detected."
fi

echo "=== [2] Hunting for post-exploitation child processes ==="
RAY_PIDS=$(pgrep -f 'raylet|gcs_server|ray/dashboard' | tr '\n' ' ')
for pid in $RAY_PIDS; do
    ps --ppid "$pid" -o pid,ppid,user,comm,args 2>/dev/null | \
        grep -E 'bash|sh$|curl|wget|nc|ncat|perl|python -c' && \
        echo "[!] Suspicious child of Ray PID $pid — preserve for forensics"
done

echo "=== [3] Scanning for recently modified executables in /tmp and /dev/shm ==="
find /tmp /dev/shm /var/tmp -type f -executable -mtime -14 2>/dev/null | head -50

echo "=== [4] Emergency containment: block dashboard ports ==="
if command -v iptables >/dev/null 2>&1; then
    iptables -C INPUT -p tcp --dport 8265 ! -s 127.0.0.1 -j DROP 2>/dev/null || \
        iptables -I INPUT -p tcp --dport 8265 ! -s 127.0.0.1 -j DROP
    iptables -C INPUT -p tcp --dport 10001 ! -s 127.0.0.1 -j DROP 2>/dev/null || \
        iptables -I INPUT -p tcp --dport 10001 ! -s 127.0.0.1 -j DROP
    echo "[+] iptables rules applied (8265, 10001 restricted to loopback)"
fi

echo "=== [5] Capture evidence BEFORE stopping Ray (per CISA Forensics Triage Requirements) ==="
mkdir -p /var/log/ray-triage-$(date +%Y%m%d)
ps auxf > /var/log/ray-triage-$(date +%Y%m%d)/processes.txt
ss -tlnp > /var/log/ray-triage-$(date +%Y%m%d)/sockets.txt
cp -r ~/.ray 2>/dev/null /var/log/ray-triage-$(date +%Y%m%d)/ray-logs/ 2>/dev/null
cp -r /tmp/ray 2>/dev/null /var/log/ray-triage-$(date +%Y%m%d)/ray-session-logs/ 2>/dev/null
echo "[+] Evidence preserved in /var/log/ray-triage-$(date +%Y%m%d)/"
echo ""
echo "NEXT STEPS: (1) Patch/upgrade Ray per vendor advisory, (2) restart with"
echo "'ray start --dashboard-host=127.0.0.1', (3) place cluster behind authenticated"
echo "reverse proxy or VPN. If no fix is available — CISA direction is to DISCONTINUE USE."

For developer workstations (macOS/Linux laptops running local Ray instances), the same script applies — pay particular attention to whether ray.init() or IDE integrations have bound the dashboard to 0.0.0.0, which is what makes the browser-delivered exploitation path viable.

Remediation

Prioritized actions, in order of urgency:

1. Inventory immediately. You cannot patch what you cannot find. Scan for listening Ray services (8265, 10001, 6379, 8080) across your environment — including developer laptops, ephemeral Kubernetes pods, and cloud GPU instances. Query your CMDB, EDR, and cloud asset inventory. ML infrastructure is notorious for shadow deployment.
2. Apply vendor mitigations. Upgrade Ray to the version the Ray Project designates as fixing CVE-2025-62593 — pull the current advisory directly from the Ray Project GitHub security advisories and the CISA KEV entry. Confirm the exact fixed version against the vendor advisory before deploying; do not assume "latest" equals "fixed."
3. Bind the dashboard to loopback. Until patched — and permanently as defense-in-depth — start Ray with ray start --dashboard-host=127.0.0.1 and never expose the dashboard or Jobs API on routable interfaces. Front any required remote access with an authenticated reverse proxy (mTLS or SSO-federated) or restrict to VPN/bastion access only.
4. Segment ML clusters. Ray head and worker nodes should live in dedicated network segments with egress filtering. There is no legitimate reason for a training cluster to initiate arbitrary outbound internet connections — deny-by-default egress and allowlist artifact repositories (PyPI, Hugging Face, internal registries).
5. Strip privileges. Ray must not run as root. Use dedicated service accounts, remove cloud IAM instance-profile permissions beyond the minimum required, and disable IMDS access where feasible — credential theft from instance metadata is the standard escalation path after ML cluster compromise.
6. Comply with KEV/BOD 26-04 deadlines. FCEB agencies: remediate per the KEV due date and satisfy CISA's Forensics Triage Requirements — preserve logs, process listings, and network state before rebuilding nodes. All organizations: if a fix is unavailable for your Ray version or deployment model, CISA's explicit direction is to discontinue use of the product. That is not hyperbole — it is the correct risk decision against confirmed active exploitation.
7. Hunt retroactively. KEV inclusion means exploitation preceded your patch. Run the detections above across at least 30 days of telemetry. Look for unexplained job submissions in Ray logs (/tmp/ray/session_latest/logs/), unexpected outbound connections from cluster nodes, and new files or users on GPU instances. If you find evidence, treat it as a full IR engagement — assume training data, model weights, and cloud credentials are compromised and rotate accordingly.

The uncomfortable truth about AI infrastructure security is that the tooling matured faster than its threat model. Ray was built for researchers on trusted networks; it is now the backbone of production AI systems reachable by adversaries. CVE-2025-62593 is the bill coming due. Patch it, segment it, authenticate it — or take it offline.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub