Back to Intelligence

CVE-2025-62593: Ray Code Injection Vulnerability Actively Exploited — Detection and Remediation Guide

SA
Security Arsenal Team
August 17, 2026
11 min read

On August 17, 2026, CISA added CVE-2025-62593 — a code injection vulnerability in the Ray Project's open-source Ray distributed computing framework — to its Known Exploited Vulnerabilities (KEV) Catalog based on evidence of active exploitation in the wild. For Federal Civilian Executive Branch (FCEB) agencies, this triggers mandatory remediation under Binding Operational Directive (BOD) 26-04, which requires rapid patching of KEV-listed CVEs. For everyone else, a KEV listing is the strongest signal available that a vulnerability is being weaponized right now, not theoretically.

Ray is not a niche library. It is the backbone of a large share of production AI/ML infrastructure — used for distributed training, hyperparameter tuning, model serving, and data processing by organizations ranging from AI startups to Fortune 500 enterprises. A code injection flaw in Ray translates directly to unauthenticated or low-friction remote code execution on some of the most valuable compute in your environment: GPU clusters that hold training data, model weights, and frequently over-privileged cloud credentials. If you run Ray anywhere — and if you have a data science or ML platform team, you almost certainly do — treat this as an incident-response-grade priority.

Technical Analysis

Affected Component

CVE-2025-62593 is a code injection vulnerability in Ray, the open-source unified compute framework maintained under the Ray Project (ray-project/ray on GitHub). Ray clusters expose a dashboard server (default TCP/8265) and a head-node API surface that accepts job submissions and cluster management requests. Historically, Ray's dashboard and job submission APIs were designed for trusted internal networks and do not enforce authentication by default — an architectural assumption that has repeatedly turned Ray clusters into soft targets when exposed to shared networks or the internet.

Code injection in this context means an attacker who can reach the vulnerable Ray API endpoint can supply crafted input that Ray interprets and executes as code — typically resulting in arbitrary command execution in the context of the Ray head-node process, and from there, lateral execution across every worker node in the cluster via Ray's own distributed task scheduling. The cluster itself becomes the attacker's lateral movement engine.

Exploitation Requirements

  • Network access to the Ray dashboard / job submission interface (default port 8265, and commonly the GCS/head service ports such as 6379 and 10001 in older default configurations).
  • No authentication by default in typical Ray deployments — Ray's own documentation has long warned that it assumes a trusted network.
  • Single request style exploitation: injection flaws in job submission handlers generally require no valid session, no credentials, and no user interaction.

Why This Hurts So Much

Ray nodes typically run as dedicated service accounts with:

  • Access to object stores (S3/GCS buckets holding training corpora and model checkpoints)
  • Cloud instance metadata credentials with broad IAM roles attached to expensive GPU instances
  • Container orchestration credentials (Ray on Kubernetes often runs with overly permissive service accounts)

Post-exploitation on a Ray head node routinely yields cloud credential theft, crypto-mining deployment across the entire cluster, and data exfiltration from mounted storage. Threat actors have been scanning for exposed Ray dashboards for years; a KEV-confirmed code injection CVE removes even the trivial friction that previously existed.

Exploitation Status

  • CISA KEV: Confirmed active exploitation as of August 17, 2026.
  • Federal mandate: BOD 26-04 requires FCEB agencies to remediate KEV-listed vulnerabilities on CISA's published timelines. Check the KEV Catalog entry for the binding due date applicable to your agency.
  • Private sector: No mandate, but the same exploitation pressure applies. Internet-exposed Ray dashboards are being found by mass scanners within minutes of coming online.

Detection & Response

The highest-fidelity detection strategy for Ray exploitation is behavioral: the Ray head-node processes (the dashboard/agent Python processes and raylet) should never spawn shells, download tools, or initiate outbound connections to untrusted infrastructure. Any of those behaviors on a Ray node is a strong post-exploitation indicator.

Sigma Rules

YAML
---
title: Ray Process Spawning Shell or Script Interpreter
id: 3f8a2c14-9b6e-4d71-a5c2-8e1f4b7d9a03
status: experimental
description: Detects Ray dashboard, agent, or raylet processes spawning shells or script interpreters, consistent with post-exploitation activity following CVE-2025-62593 code injection against the Ray head node.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/18
tags:
  - attack.execution
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'ray/dashboard'
      - 'dashboard_agent'
      - 'raylet'
      - 'gcs_server'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
  condition: selection_parent and selection_child
falsepositives:
  - Ray user jobs legitimately executing shell commands (entrypoint commands in submitted jobs) - baseline expected job names and filter known workloads
  - Legitimate Ray autoscaler activity
level: high
---
title: Suspicious Download or Execution on Ray Cluster Nodes
id: 6b1d9e47-2f5a-4c83-b7d1-3a9e5c8f2b64
status: experimental
description: Detects download-and-execute patterns and writes to execution-friendly temp paths on systems running Ray, indicative of payload staging after exploitation of the Ray dashboard or job API.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/18
tags:
  - attack.command_and_control
  - attack.t1105
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_ray_host:
    CommandLine|contains:
      - 'curl '
      - 'wget '
  selection_pipe:
    CommandLine|contains:
      - '| sh'
      - '| bash'
      - '|sh'
      - '|bash'
      - 'chmod +x'
  selection_paths:
    CommandLine|contains:
      - '/tmp/'
      - '/dev/shm/'
      - '/var/tmp/'
  condition: selection_ray_host and (selection_pipe or selection_paths)
falsepositives:
  - Cluster bootstrap and initialization scripts during node provisioning - restrict alerting to nodes outside provisioning windows
level: medium
---
title: Network Connection to Ray Dashboard from Untrusted Source
id: 9c4e7a25-1d8b-4f36-a2c9-5b7d3e6f1a48
status: experimental
description: Detects inbound connections to the Ray dashboard port (8265) where the source is outside expected cluster and management ranges. Exposed Ray dashboards are the primary attack surface for CVE-2025-62593.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/18
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort: 8265
  filter_cluster_internal:
    SourceIp|startswith:
      - '10.'
      - '172.16.'
      - '192.168.'
  condition: selection and not filter_cluster_internal
falsepositives:
  - Public cloud VPC addressing that overlaps RFC1918 - replace the filter with your actual cluster CIDRs and approved jump-host/management IPs
  - Load balancer health checks (typically TCP handshake only, no data)
level: high

Tuning note on rule three: Replace the RFC1918 prefix filter with your actual cluster CIDR ranges and approved management station IPs. If your Ray cluster is in a public cloud VPC, RFC1918 filtering alone will produce false negatives for peered or misconfigured networks — enumerate the exact subnets that should ever touch 8265.

KQL (Microsoft Sentinel / Defender)

This query hunts for Ray processes spawning shells or download tooling across both Defender for Endpoint telemetry and Syslog-ingested Linux hosts, plus network hits against the Ray dashboard port from your firewall/syslog feeds.

KQL — Microsoft Sentinel / Defender
let RayParents = dynamic(["raylet", "gcs_server", "dashboard", "dashboard_agent", "ray::"]);
let SuspiciousChildren = dynamic(["sh", "bash", "dash", "zsh", "curl", "wget", "nc", "ncat", "socat", "perl", "python", "python3"]);
let Lookback = 7d;
union isfuzzy=true
    (DeviceProcessEvents
    | where TimeGenerated > ago(Lookback)
    | where InitiatingProcessFileName has_any (RayParents) or InitiatingProcessCommandLine has_any ("ray/dashboard", "raylet", "gcs_server")
    | where FileName in~ (SuspiciousChildren)
    | project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, Source = "MDE"),
    (Syslog
    | where TimeGenerated > ago(Lookback)
    | where SyslogMessage has_any ("raylet", "dashboard_agent") and SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ")
    | project TimeGenerated, DeviceName = Computer, AccountName = "", InitiatingProcessFileName = ProcessName, InitiatingProcessCommandLine = "", FileName = "", ProcessCommandLine = SyslogMessage, Source = "Syslog"),
    (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort == 8265
    | where not (SourceIP startswith "10.") and not (SourceIP startswith "192.168.")
    | summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort
    | extend Source = "Network")
| order by TimeGenerated desc

Adjust the RFC1918 exclusions in the network section to match your cluster addressing, and consider adding a DeviceNetworkEvents clause for outbound connections from Ray nodes to non-cloud-provider destinations — a compromised Ray cluster beaconing out is often the first clean signal you will get.

Velociraptor VQL

Use this hunt artifact to sweep Ray cluster nodes for process execution anomalies and persistence artifacts planted in writable temp locations commonly used by post-exploitation payloads.

VQL — Velociraptor
-- Hunt for suspicious child processes of Ray components and staged payloads
-- in world-writable execution paths on Ray cluster nodes.

LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(/bin/(ba)?sh|curl|wget|ncat|socat|/tmp/|/dev/shm/)'

LET ray_parents = SELECT Pid, Name, CommandLine
FROM pslist()
WHERE Name =~ '(?i)(raylet|gcs_server|python)'
   AND CommandLine =~ '(?i)(ray/dashboard|dashboard_agent|raylet)'

SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime,
       if(condition=Pid in ray_parents.Pid, then='RAY_CHILD', else='SUSPECT') AS Verdict
FROM procs

UNION ALL

-- Staged executables in temp paths modified in the last 72 hours
SELECT NULL AS Pid, NULL AS Ppid, 'FILE_ARTIFACT' AS Name,
       FullPath AS CommandLine, NULL AS Exe, NULL AS Username,
       Mtime AS CreateTime, 'STAGED_FILE' AS Verdict
FROM glob(globs=['/tmp/**', '/dev/shm/**', '/var/tmp/**'])
WHERE Mtime > (now() - 259200)
  AND NOT IsDir
  AND FullPath =~ '(?i)\\.(sh|py|elf|bin)$|^[a-z0-9]{6,12}$'

Remediation Script

Run this Bash script on Ray head nodes and worker nodes to inventory the running Ray version, identify exposed listeners, and apply network-level containment while you plan the upgrade.

Bash / Shell
#!/bin/bash
# CVE-2025-62593 - Ray cluster exposure assessment and containment
# Run as root or via sudo on each Ray head/worker node

set -euo pipefail

echo "=== [1] Installed / running Ray version ==="
if command -v ray >/dev/null 2>&1; then
  ray --version || true
fi
python3 -c "import ray; print('ray python module:', ray.__version__)" 2>/dev/null || echo "ray python module not found in default interpreter"
ps -eo pid,user,args | grep -E "raylet|gcs_server|ray/dashboard" | grep -v grep || echo "No Ray processes running"

echo ""
echo "=== [2] Listening Ray service ports ==="
ss -tlnp | grep -E ":(6379|8265|10001|52365)" || echo "No default Ray ports listening"

echo ""
echo "=== [3] Check if dashboard is bound to 0.0.0.0 (EXPOSED) ==="
if ss -tlnp | grep ":8265" | grep -q "0.0.0.0"; then
  echo "[!] CRITICAL: Ray dashboard is bound to all interfaces. Restrict immediately."
else
  echo "[+] Dashboard not broadly exposed or not running"
fi

echo ""
echo "=== [4] Emergency containment: restrict dashboard port to localhost ==="
read -p "Apply iptables rule to drop external traffic to TCP/8265? [y/N] " REPLY
if [[ "$REPLY" =~ ^[Yy]$ ]]; 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
  echo "[+] External access to 8265 blocked (cluster-internal nodes must reach head via alternate allow rules)"
  iptables -L INPUT -n --line-numbers | grep 8265 || true
fi

echo ""
echo "=== [5] Upgrade Ray to the vendor-fixed release ==="
read -p "Upgrade ray via pip to latest patched release? [y/N] " REPLY2
if [[ "$REPLY2" =~ ^[Yy]$ ]]; then
  python3 -m pip install --upgrade "ray[default]"
  python3 -c "import ray; print('Upgraded to:', ray.__version__)"
fi

echo ""
echo "=== [6] Hunt: recent suspicious temp artifacts ==="
find /tmp /dev/shm /var/tmp -type f -mtime -3 \( -name "*.sh" -o -name "*.py" -o -perm -111 \) 2>/dev/null | head -50

echo ""
echo "Done. Review section 6 output and rotate any cloud credentials reachable from this host if compromise is suspected."

Remediation

  1. Upgrade immediately. Update Ray on all head and worker nodes to the fixed release published by the Ray Project. Verify the patched version in the Ray security advisory on GitHub and the CISA KEV Catalog entry. Pin the version consistently across the entire cluster — mixed-version clusters leave the weakest node as your effective patch level.
  2. FCEB agencies: Remediate within the binding due date on the KEV entry under BOD 26-04. Document remediation or approved exception in your vulnerability management system of record.
  3. Eliminate dashboard exposure. The Ray dashboard (TCP/8265) and head-node services must never be reachable from untrusted networks. Bind services to localhost or the cluster-internal interface only (--dashboard-host 127.0.0.1 where operationally feasible), enforce security group/firewall rules limiting 8265 and the GCS ports to cluster CIDRs, and audit for any public IP or load balancer exposing them. Scan your external attack surface for port 8265 today.
  4. Authenticate and segment. Ray assumes a trusted network by design — so build that trusted network deliberately. Place clusters behind an authenticated proxy or VPN, use mTLS between nodes where your deployment model supports it, and isolate Ray clusters in dedicated VPCs/subnets with egress filtering.
  5. Rotate credentials on any potentially exposed cluster. If a Ray dashboard was reachable from outside your management plane at any point, assume compromise: rotate cloud IAM credentials available to those instances, revoke Kubernetes service account tokens, and audit object storage access logs for the exposure window.
  6. Hunt retrospectively. Run the KQL and VQL hunts above across at least 30 days of telemetry. Check Ray job submission logs for entries you cannot attribute to your own teams — unknown job names or entrypoint commands are direct evidence of unauthorized use.
  7. Long-term: Treat AI/ML orchestration platforms (Ray, Kubeflow, MLflow, JupyterHub) as tier-zero attack surface in your vulnerability management program. They combine default-insecure configurations with access to your most sensitive data assets, and they are now firmly on threat actor target lists.

Related Resources

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

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.