Ray CVE-2025-62593 is a critical, actively-exploited code-injection flaw in the Ray distributed-computing framework that lets a malicious web page reach a developer's local or network-adjacent Ray cluster and execute arbitrary code, no direct network exposure required. CISA added it to the Known Exploited Vulnerabilities catalog on August 17, 2026, with a compliance deadline three days later. It carries a CVSS 4.0 score of 9.4 and is categorized as CWE-94. Ray is the de facto orchestration layer for large-scale AI training and inference, which makes this an infrastructure-tier problem, not a single-app one.

Ray's job API, exposed by default on port 8265, accepts code and shell payloads by design so that clusters can schedule work remotely. Historically these endpoints shipped without authentication. The pre-patch mitigation tried to fend off browsers by inspecting the incoming User-Agent header, on the theory that a real browser should not be submitting jobs. Treating a request header as an authorization boundary is the flaw: it is an incomplete control that does not reliably stop browser-driven job submission, and a confused-deputy chain does the rest. A developer visiting a malicious site can have their own browser pivot, via DNS rebinding, into posting a job to the local Ray instance, which then runs the attacker's code on the head node.

The community reaction was equal parts alarm and déjà vu. This is the direct successor to 2024's ShadowRay (CVE-2023-48022), where thousands of exposed Ray clusters were hijacked and maintainers long framed unauthenticated execution as a design choice for trusted perimeters. The counter-argument, now validated by a CISA directive, is that the perimeter is dead: developer laptops and browsers are the exposed surface, and orchestration tools that default to listening broadly without auth sharply raise the odds of inadvertent exposure across local and private networks.

How does the Ray browser attack actually work?

The chain turns the victim's browser into the delivery mechanism. The engineer runs Ray locally or over a VPN, then loads a malicious page or malvertising. The attacker's DNS server uses a very short TTL and rebinds the domain to a loopback or private address, so the browser treats the attacker origin as same-origin with the local Ray dashboard. JavaScript then posts to the job endpoint, the User-Agent check is evaded, and Ray schedules the payload across the cluster.

What should AI and ML platform teams do now?

Upgrade Ray to the fixed release per the project advisory, and stop treating the "trusted perimeter" as a control. Because this attack pivots through the victim's own browser, network isolation alone is not enough: loopback and private-interface binding reduce external exposure but do not stop a DNS-rebinding pivot. The controls that actually defeat rebinding are strict Host and Origin header validation, anti-CSRF protection, and real authentication (token auth or an authenticating reverse proxy) in front of the job API. Stop binding dashboards and job agents to 0.0.0.0. Post-exploitation observed in this class of attack includes stealing cloud IAM credentials via the instance metadata service, exfiltrating model weights and API keys, and hijacking GPU capacity, so rotate any credentials reachable from an exposed cluster.

Our read

Ray is the clearest example yet of AI-infrastructure technical debt: tooling that optimized for zero-friction setup inherited none of the web's last two decades of authentication hygiene. For a security program, the pillar that applies is continuous verification of the AI stack itself. Enumerate every Ray, MLflow, and inference endpoint you run, prove which ones are reachable from a browser or a developer laptop, and treat "it is only on localhost" as a claim to be tested, not trusted. Adversary simulation that includes the DNS-rebinding path is how you find these before a KEV entry does.

Reporting by The Hacker News; CVSS and KEV status per NVD and CISA. Sources linked above.

Related: stealing reasoning traces from LLM APIs and GhostSplice malicious MCP servers.