Ray CVE-2025-62593 — a 'Mozilla' User-Agent prefix was the browser-attack defense; DNS rebinding turns any web page into RCE on your AI compute cluster (CISA KEV, August 2026)

View raw markdownEdit on GitHub ↗

TL;DR

CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog on 2026-08-17 with a three-day federal remediation deadline of 2026-08-20 — confirmed directly in CISA's own KEV feed. The bug: Ray's dashboard and job-submission endpoints treated a Mozilla prefix on the User-Agent header as their defense against browser-originated attacks. Since any attacker's JavaScript controls what it sends, and DNS rebinding lets a malicious page reach localhost and network-adjacent hosts through the victim's browser, a developer merely visiting a web page (or being served a malicious ad) while Ray runs locally gets arbitrary code execution. CVSS 9.4 (CVSS 4.0) / 8.8 (CVSS 3.1). Affects Ray < 2.52.0; fixed in 2.52.0. Two campaigns are already using it: the RondoDox DDoS botnet, which adopted it two days before public disclosure, and ShadowRay 2.0, which mines cryptocurrency on unpatched Ray clusters attached to NVIDIA GPUs.

What happened

Ray is the distributed compute framework a large share of ML training, batch inference, and model-serving stacks run on — including plenty of AI products that never mention it in their docs. It ships a dashboard with job-submission endpoints (/api/jobs, /api/job_agent/jobs/) whose entire purpose is to accept and run code.

The endpoints were not unauthenticated by accident so much as by design: Ray's documented posture has long been that the dashboard belongs on a trusted network. What CVE-2025-62593 concerns is the specific control Ray added to stop a browser from reaching those endpoints on a developer's behalf — it checked whether the request's User-Agent header started with Mozilla, on the theory that browsers send such a header and command-line tools don't.

That reasoning inverts the threat model. The header is not a capability the browser withholds from attacker JavaScript; it's a string the attacker's page influences and, more importantly, a check that says nothing about who sent the request. Combined with DNS rebinding — where an attacker-controlled domain resolves first to their own server and then to 127.0.0.1 or an internal RFC1918 address, so the victim's browser treats requests to your Ray instance as same-origin — the result is that the browser becomes the attacker's proxy onto your internal network. The victim does not have to expose Ray to the internet. They only have to be running it while browsing.

This is the same root shape as this repo's localhost-is-not-a-security-boundary cluster — OpenCode, Marimo, Cline, AutoGen Studio — with DNS rebinding as the mechanism instead of a missing WebSocket Origin check. It is worth noting explicitly because "we only bind to localhost" and "we check the User-Agent" are both non-defenses against a browser-mediated attacker, and both keep reappearing in AI infrastructure.

Timeline. Disclosed 2025-11-26 by Avi Lumelsky (Oligo) and Jonathan Leitschuh. Fixed in Ray 2.52.0. The RondoDox DDoS botnet had already incorporated it two days before public disclosure. ShadowRay 2.0 subsequently targeted unpatched Ray instances with NVIDIA GPUs for cryptomining — Ray clusters are an unusually attractive cryptomining target precisely because they are provisioned with expensive GPUs and their operators expect them to run hot. CISA's KEV addition on 2026-08-17, roughly nine months after the fix shipped, reflects continued in-the-wild exploitation of instances that were never upgraded.

A note on the patched version. The Hacker News reports the fix as Ray 2.50.0; NVD states the affected range as < 2.52.0 with the fix in 2.52.0. Per this repo's practice of preferring the authoritative record and stating the disagreement rather than silently picking one: treat 2.52.0 as the minimum safe version.

Am I affected?

# Version check — anything below 2.52.0 is affected.
python -c "import ray; print(ray.__version__)" 2>/dev/null
pip show ray 2>/dev/null | grep -i '^version'
grep -rn '^ray\b\|^ray\[' requirements*.txt pyproject.toml poetry.lock 2>/dev/null

# Is the dashboard listening, and on what interface?
ss -tlnp 2>/dev/null | grep -E ':(8265|10001|6379)\b'

Do not treat "it's only on localhost" as a clean result. That is the exact configuration this vulnerability targets. If you ran Ray < 2.52.0 on a machine you also browsed the web from, you were in scope regardless of firewall rules.

Look for the two known post-exploitation outcomes:

  • Cryptomining (ShadowRay 2.0) — sustained GPU utilization with no corresponding job in Ray's own job history; unexpected processes on worker nodes; unexplained egress to mining pools.
  • Botnet enrollment (RondoDox) — unexpected outbound connections and persistence mechanisms on cluster hosts.

Also enumerate what the cluster held: Ray jobs routinely run with cloud credentials, model-registry tokens, and data-warehouse access. As with every credential-hub finding in this repo, the blast radius is every upstream credential the Ray process could reach, not just Ray itself.

If you are affected

Prevention

The transferable lesson: a request header is not an identity, and 127.0.0.1 is not an access-control boundary when the victim runs a browser. Any local service that executes code needs a real authentication token bound to the session plus an Origin/Host check — the same two controls missing across the whole localhost cluster this repo tracks.

Sources