CISA added CVE-2025-62593 — a critical remote-code-execution flaw in Ray, the distributed AI framework used by OpenAI, Netflix, and Uber — to its Known Exploited Vulnerabilities catalog on August 17. Federal agencies had three days to patch. The real alarm isn’t the severity score. It’s the attack vector: an adversary doesn’t need access to your servers. They just need you to visit the wrong webpage while Ray is running on your machine.
Your Browser Is the Attack Surface #
Ray’s dashboard and job API endpoints — /api/jobs
and /api/job_agent/jobs/
— have no authentication. This was a deliberate design decision: Ray was built for trusted, isolated cluster environments, not for public-facing deployments. The only browser-side defense was a check for whether the HTTP User-Agent
header started with “Mozilla.”
That check is bypassed via DNS rebinding. An attacker registers a domain, sets the TTL to nearly zero, and serves JavaScript to anyone who visits. The script makes a request to the attacker’s domain; seconds later, the attacker’s DNS server rotates that domain’s resolution to 127.0.0.1
. The browser, treating both resolutions as the same origin, now allows the JavaScript to hit your local Ray API. From there, the attacker submits a malicious job. Ray executes it as the user running the process — full local code execution, no server misconfiguration required. The Hacker News has a full technical breakdown of the exploit chain.
Firefox and Safari are specifically cited in the CISA advisory as vulnerable browsers for this attack path. If you run Ray during development and use either browser, you are in scope.
Attackers Are Already Inside AI Clusters #
This isn’t theoretical. ShadowRay 2.0, a campaign tracked by Oligo Security and attributed to a threat actor called IronErn440, has been exploiting Ray infrastructure since at least September 2024. The campaign has evolved to incorporate CVE-2025-62593’s browser-based vector, and it’s now building a self-propagating botnet from compromised Ray deployments.
Over 200,000 Ray servers were found exposed to the internet in recent scans, a tenfold increase from the original ShadowRay disclosure. Compromised machines run XMRig to mine Monero, while capping GPU usage at 60% to avoid triggering monitoring alerts. But compute theft is the least of it. The campaign also exfiltrates MySQL and PostgreSQL credentials, AWS, GCP, and Azure tokens, SSH private keys, proprietary AI model weights, and source code. If your ML pipeline gives Ray access to cloud credentials — and most do — treat those credentials as compromised.
Check Every Place Ray Lives #
The obvious move is patching the Ray package wherever it’s installed. But Ray tends to spread across environments in ways that don’t always get updated together:
Developer workstations— the primary browser-based attack vector** CI/CD runners**— pinned Ray versions in runner images don’t auto-update** Container images**— base images may bundle older Ray versions** Kubernetes workloads**— Ray Serve or Ray clusters exposed via LoadBalancer services** Cloud data processing clusters**— Ray bound to0.0.0.0
, exposed to all interfaces
Patch Now, Then Harden #
The fix is straightforward. Ray 2.52.0 addresses CVE-2025-62593 with proper browser-origin validation.
pip install "ray>=2.52.0"
python -c "import ray; print(ray.__version__)"
ss -tlnp | grep 8265
If port 8265 shows 0.0.0.0:8265
, you’re binding to all interfaces. Start Ray bound to localhost instead:
ray start --head --dashboard-host=127.0.0.1
For teams running Ray in CI/CD or on clusters, add a firewall rule restricting access to the Ray dashboard port. Don’t rely on “nobody knows this endpoint exists” as a security control — ShadowRay proved that assumption expired two years ago.
Ray’s no-auth design made sense when it was a research tool for HPC environments. That era ended when it became the compute backbone of production AI systems at companies like OpenAI and Netflix. CVE-2025-62593 is the bill for that transition coming due. Patch your environments, rotate any credentials Ray had access to, and stop treating local ML tooling as out-of-scope for security review.