CISA KEV Alert: Actively Exploited Ray Dashboard RCE Flaw — Detection, Containment, and Hardening Guide

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a critical vulnerability in Ray — the open-source, Python-native distributed computing framework used to scale AI and machine learning workloads — to its Known Exploited Vulnerabilities (KEV) catalog, citing confirmed evidence of active exploitation in the wild.

This is not a theoretical risk. CISA KEV inclusion means threat actors are weaponizing this flaw right now, against real targets. If your organization operates Ray clusters — whether for LLM training, hyperparameter tuning, reinforcement learning, or distributed inference — your AI/ML infrastructure is a live target. These environments are particularly attractive to attackers because they typically run with broad compute privileges, hold valuable proprietary models and training data, and are frequently deployed with minimal security controls in research or staging contexts.

Ray's GitHub project has well over 30,000 stars, and the framework underpins ML workloads at organizations ranging from startups to hyperscalers. The blast radius of a compromise here extends beyond a single host: a breached Ray head node gives an attacker orchestration-level control over an entire distributed cluster.

Technical Analysis

What Is Ray and Why Is It Exposed?

Ray is designed to distribute Python workloads across clusters of machines. Its architecture includes:

• Head node: Runs the GCS (Global Control Store), dashboard, and job submission APIs
• Worker nodes: Execute distributed tasks scheduled by the head node
• Ray Dashboard: A web interface (default port 8265) exposing job submission, cluster state, and — critically — the Jobs API

The core architectural problem at the heart of this vulnerability class is that Ray was designed with the assumption that it operates inside a trusted network perimeter. The Jobs API accepts unauthenticated job submissions, meaning anyone who can reach the dashboard endpoint can submit arbitrary Python code for execution across the cluster. There is no built-in authentication layer on the job submission endpoint — a design decision the project maintainers have documented, but one that is catastrophically dangerous in practice when dashboards are exposed to untrusted networks.

Attack Chain (Defender's View)

1. Discovery: Attackers scan for exposed Ray dashboards on port 8265 (and increasingly on non-standard ports, as defenders catch on). Internet scan data has historically shown thousands of reachable instances.
2. Reconnaissance: Unauthenticated GET requests to /api/version and /api/jobs/ confirm the target is live and enumerate existing jobs.
3. Execution: A POST to /api/jobs/ with a malicious entrypoint field submits a job containing attacker-controlled Python or shell commands. The head node executes it and can propagate tasks to all workers.
4. Post-exploitation: Observed tradecraft in campaigns against Ray includes cryptomining deployment, theft of cloud credentials from instance metadata services (IMDS), exfiltration of training data and model weights, and persistence via cron, systemd units, or SSH key injection.

Exploitation Status

• Confirmed active exploitation — this is the trigger for CISA KEV inclusion
• CISA KEV catalog: Listed as of this week. Federal civilian agencies are bound by BOD 22-01 remediation timelines (typically three weeks for newly added CVEs); private-sector organizations should treat the same deadline as a benchmark
• Exploitation complexity: Trivial. No authentication, no user interaction, publicly documented API abuse

Who Is Affected

Any organization running Ray clusters where:

• The dashboard/Jobs API (port 8265) is reachable from untrusted networks or the internet
• Clusters were deployed with default configurations and no network-level access control
• AI/ML platform teams deployed Ray without security review — an extremely common pattern given how quickly ML infrastructure gets stood up

Shadow IT is a major concern here. Data science teams routinely spin up Ray clusters on cloud VMs for experiments and never tear them down. Your vulnerability scanner may not even know these assets exist.

Detection & Response

The detections below target the observable behaviors of Ray dashboard exploitation: unauthenticated API interaction, job submission spawning shells or interpreters, and post-exploitation activity from Ray processes.

Sigma Rules

---
title: Ray Dashboard Process Spawning Shell or Interpreter
id: 8c4a2f61-3b7d-4e59-a1c8-9d2e5f7a3b41
status: experimental
description: Detects Ray head node or worker processes spawning shells, interpreters, or download utilities — consistent with malicious job submission via the unauthenticated Ray Jobs API.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.execution
  - attack.initial_access
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'ray::'
      - 'raylet'
      - 'gcs_server'
      - 'dashboard'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Ray jobs invoking subprocesses (data pipelines frequently shell out) — tune by baseline of known job entrypoints
level: high
---
title: Ray Jobs API Submission from External Source
id: 2f7b9c14-6a3e-4d81-b5f2-8e1c4a6d9f03
status: experimental
description: Detects HTTP POST requests to the Ray Jobs API endpoint, indicating job submission. Any POST from outside the approved cluster management network should be treated as hostile given the API's lack of authentication.
references:
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/api/jobs/'
      - '/api/jobs'
  selection_method:
    cs-method: 'POST'
  condition: selection_uri and selection_method
falsepositives:
  - Legitimate job submissions from pipeline orchestrators — restrict by source IP allowlist where possible
level: medium
---
title: Cloud Instance Metadata Access from Ray Process Context
id: 5e1d8a37-9c4f-4b26-a7d3-3f8e2c5b1a96
status: experimental
description: Detects access to cloud instance metadata services (169.254.169.254) from Ray-associated processes, consistent with credential theft following Ray cluster compromise.
references:
  - https://attack.mitre.org/techniques/T1552/
  - https://attack.mitre.org/techniques/T1552.005/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1552.005
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationIp:
      - '169.254.169.254'
      - '100.100.100.200'
    Image|contains:
      - 'python'
      - 'curl'
      - 'wget'
  condition: selection
falsepositives:
  - Cloud-native SDKs legitimately querying IMDS for credentials — correlate with parent process and job origin
level: medium

KQL — Microsoft Sentinel / Defender

For Linux-based Ray infrastructure, ensure Syslog and any WAF/load-balancer logs are ingested into Sentinel. The following hunt identifies suspicious job submissions and child process execution patterns associated with Ray exploitation:

// Hunt 1: External HTTP requests hitting Ray dashboard / Jobs API
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where (DestinationPort == 8265 or RequestURL has_any ("/api/jobs", "/api/version"))
| where RequestMethod == "POST" or RequestURL has "/api/jobs"
| where ipv4_is_private(SourceIP) == false
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, RequestMethod, RequestURL, DeviceAction
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, RequestURL, DestinationIP
| order by RequestCount desc;

// Hunt 2: Ray processes spawning shells or download tooling (via Syslog process audit)
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName has_any ("python", "python3", "bash", "sh", "curl", "wget", "nc")
| where SyslogMessage has_any ("ray::", "raylet", "169.254.169.254", "/api/jobs")
   or (SyslogMessage has_any ("curl", "wget") and SyslogMessage has "http")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: IMDS access from compute workloads (credential theft post-compromise)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteIP == "169.254.169.254"
| where InitiatingProcessFileName has_any ("python", "curl", "wget", "bash")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort
| order by TimeGenerated desc

Velociraptor VQL

Use this hunt artifact across Linux endpoints in your ML infrastructure to surface suspicious child processes of Ray components and persistence artifacts left behind by cluster intrusions:

-- Hunt for suspicious child processes of Ray components and post-exploitation persistence
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(curl|wget|base64|nc |ncat|chmod \+x|/tmp/|/dev/shm/)'
   OR Name =~ '(?i)(xmrig|kdevtmpfs|kthreaddi|minerd)'

-- Separately, enumerate persistence commonly planted after Ray compromise
SELECT FullPath, Mtime, Size
FROM glob(globs=['/etc/cron.d/*', '/var/spool/cron/*', '/etc/systemd/system/*.service', '/root/.ssh/authorized_keys', '/home/*/.ssh/authorized_keys'])
WHERE Mtime > (now() - 604800)
ORDER BY Mtime DESC

Remediation and Verification Script

Run this on suspected Ray head nodes and workers to check for exposure, evidence of malicious job submissions, and common persistence mechanisms:

#!/bin/bash
# Ray Compromise Assessment & Exposure Check — Security Arsenal
# Run as root on Ray head/worker nodes

echo "=== [1] Ray version and process inventory ==="
python3 -c "import ray; print('Ray version:', ray.__version__)" 2>/dev/null || echo "ray not importable in default env"
ps aux | grep -E 'raylet|gcs_server|dashboard|ray::' | grep -v grep

echo -e "\n=== [2] Dashboard exposure check (port 8265) ==="
ss -tlnp | grep -E ':8265|:6379|:10001' || echo "Ray ports not listening"
# Check if dashboard is bound to 0.0.0.0 (exposed) vs 127.0.0.1
ss -tln | grep ':8265' | grep -q '0.0.0.0' && echo "[!] WARNING: Dashboard bound to all interfaces — EXPOSED" || echo "[OK] Dashboard not globally bound"

echo -e "\n=== [3] Recent Ray job submissions (audit trail) ==="
ls -lat /tmp/ray/session_latest/logs/ 2>/dev/null | head -20
grep -rE 'entrypoint|job_submission' /tmp/ray/session_latest/logs/dashboard*.log 2>/dev/null | tail -30

echo -e "\n=== [4] Persistence artifact sweep ==="
ls -lat /etc/cron.d/ /var/spool/cron/ 2>/dev/null | head -20
find /etc/systemd/system/ -name '*.service' -mtime -14 -exec ls -la {} \; 2>/dev/null
for d in /root /home/*; do [ -f "$d/.ssh/authorized_keys" ] && echo "-- $d/.ssh/authorized_keys (mtime:)" && stat -c '%y %n' "$d/.ssh/authorized_keys"; done

echo -e "\n=== [5] Network connections to suspicious destinations ==="
ss -tnp | grep -E '169.254.169.254|:4444|:5555|:3333' || echo "No matches"

echo -e "\n=== [6] Cryptominer indicators ==="
ps aux | grep -iE 'xmrig|minerd|kdevtmpfs|kthreaddi' | grep -v grep || echo "No known miner processes"
ls -la /dev/shm/ /tmp/ 2>/dev/null | grep -vE '^d|^total' | head -20

echo -e "\n=== Assessment complete. If dashboard is exposed or suspicious jobs found, isolate the node and begin IR. ==="

Remediation

Priority 1 — Immediate containment (today):

1. Verify the dashboard is not internet-reachable. Check security groups, firewall rules, and load balancer configs for port 8265 (and the GCS port 6379, client port 10001). Query your external attack surface management tooling and run authenticated scans against cloud accounts for listening Ray services.
2. Bind the dashboard to localhost or a management interface. If the dashboard must be reachable, place it behind an authenticated reverse proxy (e.g., nginx with SSO/mTLS) or restrict access via VPN/bastion only.
3. Inventory shadow Ray deployments. Work with data science and ML platform teams to enumerate all clusters — including ephemeral experiment infrastructure that never went through security review.

Priority 2 — Patch and upgrade:

4. Upgrade Ray to the latest available release per the official Anyscale/Ray project guidance. Review the Ray security documentation and the CISA KEV catalog entry for this vulnerability. Because Ray's maintainers have historically framed dashboard exposure as a deployment concern rather than a code defect, patching alone is insufficient — architectural controls (network isolation, authenticated ingress) are the durable fix.
5. Meet the CISA BOD 22-01 deadline. Federal agencies must remediate within the mandated window (typically ~3 weeks from KEV addition). Private organizations should adopt the same SLA — active exploitation means the clock is already running.

Priority 3 — Harden the architecture:

6. Deploy network segmentation. Ray clusters should live in dedicated VPCs/subnets with egress filtering. Workers should not be able to reach the internet directly; route through a controlled NAT with logging.
7. Protect cloud credentials. Enforce IMDSv2 on AWS, use short-lived instance roles with least privilege, and alert on metadata service access from unexpected processes (see KQL Hunt 3 above).
8. Add authentication at the perimeter. Ray does not authenticate the Jobs API — compensate with an authenticating proxy, mTLS between nodes, and service-mesh policy where applicable.
9. Centralize logging. Ship Ray dashboard logs, job submission records, and node-level Syslog/auditd to your SIEM. You cannot detect job-submission abuse without the dashboard logs leaving the box.
10. Threat-hunt retroactively. Pull historical dashboard logs and network flow data. Given confirmed active exploitation, assume any cluster that has been exposed for weeks may already be compromised — check for miner persistence, rogue SSH keys, and anomalous outbound traffic before declaring clean.

If compromise is suspected: Isolate the cluster at the network layer (do not terminate instances — preserve forensic state), snapshot volumes, rotate all cloud credentials and secrets accessible from the cluster, and treat proprietary model weights and training data as potentially exfiltrated.

Related Resources

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