Ray-Project Ray — Dashboard/API Code Injection via DNS-Rebinding User-Agent Bypass

Ray is an open-source, Python-native distributed compute engine widely used to run AI/ML training and inference clusters. Every Ray head node ships a Dashboard and Jobs API (default port 8265) with no authentication by design — the project's long-standing security model assumed the network around Ray was trusted, and the only defense against a hostile browser reaching that API was a check that the request's User-Agent header started with "Mozilla". That check is trivially bypassed: the fetch spec lets Firefox and Safari override the User-Agent on a request (Chrome has a bug that happens to block this, which is the only reason Chrome users are not equally exposed). Combine that bypass with DNS rebinding — a technique that makes a browser resolve an attacker-registered domain to 127.0.0.1 or another internal address after the same-origin check has already passed — and an attacker-controlled webpage or malicious ad can silently drive a victim's browser to POST a job to /api/jobs/ on any Ray dashboard the victim's machine can reach, with an entrypoint the attacker chooses. Ray executes it. The victim never has to install anything or click "allow" — visiting a page while Ray happens to be running is enough.

The attacker's objective is arbitrary code execution with the privileges of the Ray process — typically a developer's own shell, or the service account running a training/inference cluster — followed by credential, model, and dataset theft, lateral movement into whatever cloud or internal infrastructure that Ray host can reach, and (per the observed "ShadowRay 2.0" activity) GPU-cycle theft via cryptomining on expensive training hardware. CISA added CVE-2025-62593 to KEV on 2026-08-17 citing active exploitation, with a three-day FCEB remediation window (due 2026-08-20) — and per Bitsight reporting cited by multiple outlets, the RondoDox botnet was already probing for this exact flaw two days before the CVE was publicly disclosed on 2025-11-26.

The single highest-value defensive move is not a detection rule — it's closing the precondition: nothing in this attack chain works if the Ray dashboard is bound to loopback only and firewalled from any network the attacker's browser (via the victim) can reach. Everything downstream of that (DNS-rebinding telemetry, unauthenticated-API abuse, anomalous child processes off raylet/gcs_server) is real and worth hunting, but it is defense-in-depth for a bug whose root fix is "don't expose the dashboard, and patch to 2.52.0+ where token auth finally exists."

Defender priority: patch to Ray ≥2.52.0 (2.52.1 preferred) and confirm no Ray dashboard/Jobs API port (8265, plus GCS 6379 and worker ports) is reachable from outside loopback/a private, firewalled subnet — before investing in the behavioral detections in this pack. An internet-exposed, unpatched Ray dashboard is compromised by policy; treat it as such and start incident response, don't wait for a hunt hit.

All sources below were fetched on 2026-08-22 and saved verbatim to Ray-CVE-2025-62593-Hunt-sources/ for provenance. No atomic IOC in this pack is sourced from anywhere outside this table.

Web Hunter decisions: (1) No source — including the vendor advisory — publishes an atomic hash, IP, or C2 domain, because this is a logic/config vulnerability in Ray itself, not a malware family; the IOC table and appendix in this pack are behavioral by design, per the task's own instruction not to fabricate atomic indicators. (2) NVD's CVSS 3.x score (8.8) differs from GitHub's CNA-assigned CVSS 4.0 score (9.4) per Resecurity; this pack uses the CNA/vendor score (9.4) as primary since it's the one GHSA and KEV both track, and notes the NVD figure as a secondary data point. (3) "RondoDox" and "ShadowRay 2.0" are carried forward as named campaigns/context in the exec summary and IOC table, not as verified indicators to detect on directly — they are attributions from secondary journalism, not the primary vendor/gov sources.

Hunt hypotheses

1. (High) A Ray dashboard/GCS process is listening on 8265 (or other Ray ports) on a non-loopback interface reachable by a browser — the precondition for the whole chain.
2. (High) A shell or interpreter is spawned directly from raylet or gcs_server — the highest-fidelity signal that a job's entrypoint executed attacker code.
3. (Medium) A Ray-context Python worker process (job execution, titled ray::... at the OS level but recorded by the sensor as a python image) spawns an unexpected shell whose command line references Ray's own session paths.
4. (Medium) A browser process (Firefox/Safari) opens a direct connection to a local or internal host on port 8265 — the confused-deputy step where the victim's browser becomes the attacker's proxy.
5. (Medium, investigate-only) The same domain resolves to multiple distinct IP addresses — including loopback/RFC1918 — in a short window: the DNS-rebinding fingerprint.
6. (Medium) A known GPU-cryptomining binary is spawned from a Ray core process — the "ShadowRay 2.0" post-exploitation pattern.
7. (Low-Medium) A Ray core process opens an outbound connection to a common cryptomining-pool port, catching a renamed/repacked miner binary that Q6's name list would miss.

Attack chain

No atomic hashes, IPs, or C2 domains have been published for this CVE by any source reviewed (vendor GHSA, CISA KEV, or the four independent write-ups). This is a design/logic flaw in Ray itself, not a malware family with static artifacts — the attacker's DNS-rebinding domain is registered per-campaign and none of the reviewed sources disclosed one. Every row below is a behavioral or configuration indicator; see §10 for the copy-paste blocks.

These checks cover the parts of the attack chain (steps 4-5) that Falcon endpoint telemetry does not natively see — the Jobs API call itself only exists in Ray's own dashboard/API access logs.

1. Ray dashboard/API access-log review (if ingested to any log platform)

If the Ray dashboard's HTTP access log is captured anywhere (reverse proxy, application log shipper, or a custom LogScale ingest), grep/search for:

POST /api/jobs/ or POST /api/job_agent/jobs/
User-Agent NOT starting with "Mozilla"    // the exact bypass condition per Ray's own advisory
                                            // sample observed value in the vendor PoC: "User-Agent: Other"

Any hit is a near-certain exploitation attempt — the legitimate Ray CLI/SDK does not send browser-style requests to this endpoint from an external origin.

2. Ray version & dashboard-bind configuration audit

Run on every host known or suspected to run Ray (fleet inventory, package manager, or container image scan):

pip show ray 2>/dev/null | grep -i version
ray --version
ps aux | grep -E "raylet|gcs_server|dashboard" | grep -v grep
# Confirm the dashboard is NOT bound to 0.0.0.0 — the flag that widens exposure:
ps aux | grep -- "--dashboard-host" 

Flag any result showing Ray <2.52.0, or a --dashboard-host value other than 127.0.0.1/localhost on a host with any network reachability beyond a fully trusted, segmented cluster subnet.

3. Ray token-authentication status audit (post-patch verification)

Ray 2.52.0+ ships an optional, disabled-by-default token-auth feature. Confirm it is actually enabled after patching — an unpatched-then-patched host that never turned auth on is still relying on network exposure alone:

ray status
env | grep -i RAY_AUTH   # or check the equivalent startup flag/config per Ray 2.52+ docs

This threat has no published atomic IOCs — the CSV block below intentionally carries only REPLACE_WITH_… placeholders and behavioral entries. Populate the placeholders only if your own incident response turns up a campaign-specific artifact (e.g., an attacker DNS-rebinding domain observed in your own logs); do not invent values to fill the block.

type,value,action,severity,expiration,description,tags
domain,REPLACE_WITH_OBSERVED_REBINDING_DOMAIN,detect,high,2027-02-22,CVE-2025-62593 DNS-rebinding domain observed in your own IR,campaign:Ray-CVE-2025-62593
ipv4,REPLACE_WITH_OBSERVED_ATTACKER_IP,detect,high,2027-02-22,CVE-2025-62593 attacker infrastructure observed in your own IR,campaign:Ray-CVE-2025-62593
sha256,REPLACE_WITH_OBSERVED_PAYLOAD_HASH,detect,high,2027-02-22,Payload dropped via CVE-2025-62593 job entrypoint observed in your own IR,campaign:Ray-CVE-2025-62593

ParentImage: raylet | gcs_server  ->  Child: shell/interpreter (cmd, powershell, sh, bash, python)
Listening socket: 0.0.0.0:8265 or non-loopback bind of the Ray dashboard/Jobs API
HTTP: POST /api/jobs/ or /api/job_agent/jobs/ with User-Agent NOT starting with "Mozilla"
DNS: same domain resolving to a public IP then to 127.0.0.1/RFC1918 within a short window
Process: xmrig/ccminer/nbminer/t-rex/phoenixminer/lolminer/nanominer/ethminer/kinsing spawned from raylet/gcs_server/python

RondoDox botnet - attempted pre-disclosure exploitation of CVE-2025-62593 (per Bitsight/Resecurity); did not
  successfully bypass Ray's browser check per Resecurity's analysis. No atomic RondoDox IOC in this pack.
"ShadowRay 2.0" - press-coined name for GPU-cryptomining campaigns against unpatched, exposed Ray instances.
  No atomic indicators published; hunt via Q6/Q7 behavior.

[ ] Ray version >= 2.52.0 (2.52.1 preferred) on every host/image/cluster
[ ] Dashboard NOT bound to 0.0.0.0 -- confirm --dashboard-host is 127.0.0.1 or a firewalled private address
[ ] Port 8265 (and 6379 GCS) not reachable from any untrusted network or the public internet
[ ] Ray 2.52+ token authentication enabled (it ships disabled by default)
[ ] KubeRay dashboard Service type is ClusterIP, not LoadBalancer/NodePort, with a NetworkPolicy restricting ingress
[ ] Credentials/tokens on any historically-exposed Ray host rotated

Playbook 1 — Upgrade Ray and verify version (Linux/macOS)

Prerequisites: pip/conda access to the target environment; a maintenance window if Ray is actively serving production jobs. Reboot required: No — restart the Ray process/cluster, not the host. Rollback: pin back to the prior version with pip install ray==<previous_version> if the upgrade breaks a dependency; keep the prior requirements.txt/lockfile on hand before upgrading.

pip install -U "ray>=2.52.0"
ray --version
# Restart any running cluster so the new binary takes effect:
ray stop
ray start --head   # or your cluster's normal start invocation

Playbook 2 — Bind dashboard to loopback and enable token auth

Prerequisites: Ray ≥2.52.0 already installed (Playbook 1). Know whether any legitimate remote user needs dashboard access (if so, front it with an authenticated reverse proxy/VPN instead of a public bind). Reboot required: No — Ray process restart only. Rollback: revert the start flags to the prior invocation; if a documented remote-access need existed, restore the previous reverse-proxy config rather than re-exposing the raw port.

# Bind dashboard to loopback only (default in recent Ray, but verify explicitly):
ray start --head --dashboard-host=127.0.0.1

# Enable token authentication (Ray 2.52+, disabled by default -- exact flag/env
# var per your installed Ray minor version's release notes; verify against
# `ray start --help` on your installed version before scripting this into CI):
# RAY_ENABLE_AUTH=1 ray start --head --dashboard-host=127.0.0.1
ray status

Playbook 3 — Host/network firewall rule blocking external access to Ray ports

Prerequisites: sudo/root on the host, or cloud security-group edit access; confirm no legitimate cross-host cluster traffic will be blocked (check worker port range for multi-node clusters first). Reboot required: No. Rollback: remove the added rule (ufw delete deny ... / revert the security-group change) to restore prior connectivity.

# Linux host firewall (ufw example) -- deny 8265/6379 from anything outside a trusted subnet:
sudo ufw deny from any to any port 8265 proto tcp
sudo ufw allow from 10.0.0.0/8 to any port 8265 proto tcp
sudo ufw deny from any to any port 6379 proto tcp
sudo ufw allow from 10.0.0.0/8 to any port 6379 proto tcp
sudo ufw reload

# Cloud security group (AWS CLI example) -- remove any 0.0.0.0/0 ingress on 8265/6379:
aws ec2 revoke-security-group-ingress --group-id sg-REPLACE_WITH_SG_ID --protocol tcp --port 8265 --cidr 0.0.0.0/0
aws ec2 revoke-security-group-ingress --group-id sg-REPLACE_WITH_SG_ID --protocol tcp --port 6379 --cidr 0.0.0.0/0

Playbook 4 — Kubernetes NetworkPolicy restricting KubeRay dashboard ingress

Prerequisites: a CNI plugin that enforces NetworkPolicy (Calico, Cilium, etc. -- confirm before relying on this, some default CNIs silently no-op policies); cluster-admin or namespace-admin access. Reboot required: No. Rollback: kubectl delete networkpolicy ray-dashboard-restrict -n <namespace> to remove the policy and restore prior (unrestricted) ingress.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ray-dashboard-restrict
  namespace: REPLACE_WITH_RAY_NAMESPACE
spec:
  podSelector:
    matchLabels:
      ray.io/node-type: head
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              trusted-ray-client: "true"
      ports:
        - protocol: TCP
          port: 8265

Playbook 5 — Post-hardening verification spot-check (CQL)

Prerequisites: Playbooks 1-4 applied; Falcon sensor deployed and reporting for the target hosts. Reboot required: No -- this is a read-only verification query. Rollback: none required -- it changes nothing.

// HUNT: Post-hardening spot-check -- confirm Q1's non-loopback exposure is gone
#event_simpleName=NetworkListenIP4
| LocalPort=8265
| LocalAddressIP4!="127.0.0.1"
| table([ComputerName, aid, LocalAddressIP4, LocalPort])
// Expected result after Playbooks 1-3: zero rows outside documented, trusted cluster subnets.

Validation gates: see §11 for the full gate table. Summary — confirm telemetry coverage and baseline FP before enabling any query; verify the flagged IP4Records field on Q5 in your own tenant; only Q2 and Q6 are recommended for IOA promotion at this time.