CVE-2023-48022: Anyscale Ray RCE Vulnerability

CVE-2023-48022 Overview

CVE-2023-48022 is a critical remote code execution vulnerability affecting Anyscale Ray, a popular open-source framework for building distributed applications. The vulnerability allows remote attackers to execute arbitrary code via the job submission API without requiring authentication. This vulnerability has been dubbed "ShadowRay" by security researchers and represents a significant risk for organizations running Ray clusters that are inadvertently exposed to untrusted networks.

The vendor (Anyscale) maintains that Ray is designed for use within strictly controlled network environments and is not intended to be exposed to the public internet. However, real-world deployments have shown that many Ray instances are misconfigured and accessible externally, making this vulnerability particularly dangerous in practice.

Critical Impact

Unauthenticated remote attackers can execute arbitrary code on Ray cluster nodes, potentially leading to complete system compromise, data exfiltration, cryptocurrency mining, and lateral movement within affected networks.

Affected Products

• Anyscale Ray version 2.6.3
• Anyscale Ray version 2.8.0
• Anyscale Ray versions prior to 2.52.0 without token authentication

Discovery Timeline

• 2023-11-28 - CVE-2023-48022 published to NVD
• 2025-12-17 - Last updated in NVD database

Technical Details for CVE-2023-48022

Vulnerability Analysis

This vulnerability stems from the lack of authentication on Ray's job submission API, which is exposed by default on the Ray Dashboard. The job submission API allows users to submit arbitrary Python code for execution on Ray cluster nodes. When Ray clusters are deployed without proper network isolation or authentication, any attacker with network access to the Ray Dashboard can submit malicious jobs that execute with the privileges of the Ray process.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery), though its primary impact is remote code execution. The job submission API accepts Python code payloads and executes them on worker nodes, providing attackers with a direct path to code execution without any authentication barriers in default configurations.

Root Cause

The root cause of CVE-2023-48022 is the design decision to ship Ray without authentication enabled by default. While Anyscale's documentation explicitly states that Ray should only be deployed in trusted network environments, the framework lacks built-in authentication mechanisms in the affected versions. This "insecure by default" configuration, combined with the powerful job submission API that accepts arbitrary code, creates a dangerous attack surface when Ray clusters are exposed to untrusted networks.

Token authentication was later introduced in Ray version 2.52.0 as an optional security measure, but it must be explicitly enabled by administrators.

Attack Vector

The attack vector for CVE-2023-48022 is network-based and requires no user interaction or special privileges. An attacker who can reach the Ray Dashboard (typically on port 8265) can submit arbitrary Python code for execution. The attack flow involves discovering exposed Ray instances, submitting a malicious job payload via the job submission API, and achieving code execution on the Ray cluster nodes.

Attackers have been observed exploiting this vulnerability in the wild to deploy cryptocurrency miners, establish reverse shells, and exfiltrate sensitive data including AI model weights and cloud credentials. The MITRE ATLAS case study documents real-world exploitation campaigns targeting exposed Ray clusters.

Detection Methods for CVE-2023-48022

Indicators of Compromise

• Unexpected processes spawned by Ray worker processes, particularly cryptocurrency miners or reverse shell connections
• Anomalous network connections from Ray cluster nodes to external IP addresses
• Unusual job submissions in Ray Dashboard logs from unknown source IP addresses
• Presence of unauthorized Python scripts or binaries in Ray cluster temporary directories
• Increased CPU usage on Ray nodes indicating cryptomining activity

Detection Strategies

• Monitor Ray Dashboard access logs for job submissions from unexpected source IPs
• Implement network intrusion detection rules for traffic patterns associated with Ray job submission API exploitation
• Deploy endpoint detection and response (EDR) solutions to identify malicious processes spawned by Ray workers
• Scan for exposed Ray Dashboard instances using port scanning tools targeting port 8265

Monitoring Recommendations

• Enable comprehensive logging for Ray job submissions including source IP, job content, and execution results
• Set up alerts for Ray Dashboard access from non-whitelisted IP ranges
• Monitor Ray cluster nodes for child processes that deviate from normal ML workload patterns
• Implement network flow analysis to detect command-and-control communications from Ray nodes

How to Mitigate CVE-2023-48022

Immediate Actions Required

• Audit network exposure of Ray clusters and ensure they are not accessible from untrusted networks
• Implement network segmentation to isolate Ray clusters within trusted internal networks
• Upgrade to Ray version 2.52.0 or later and enable token authentication
• Review Ray Dashboard access logs for signs of unauthorized job submissions

Patch Information

Anyscale has introduced token authentication in Ray version 2.52.0 and later to address this vulnerability. Organizations should upgrade to the latest Ray version and explicitly enable token authentication following the guidance in the Ray Token Authentication Documentation. The Ray Security Documentation provides comprehensive guidance on securing Ray deployments.

For detailed technical analysis and exploitation details, refer to the Bishop Fox research blog and the Vicarius vulnerability analysis.

Workarounds

• Deploy Ray clusters behind a VPN or bastion host to prevent direct internet exposure
• Implement firewall rules to restrict Ray Dashboard access (port 8265) to trusted IP addresses only
• Use network policies in Kubernetes environments to limit ingress to Ray services
• Consider using a reverse proxy with authentication in front of the Ray Dashboard as an additional security layer

# Example: Restrict Ray Dashboard access using iptables
# Allow only internal network access to Ray Dashboard
iptables -A INPUT -p tcp --dport 8265 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8265 -s 172.16.0.0/12 -j ACCEPT
iptables -A INPUT -p tcp --dport 8265 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 8265 -j DROP