Ray dashboard code injection, unauthenticated job-submission endpoints guarded only by a User-Agent string check, bypassable from Firefox and Safari via fetch() combined with DNS rebinding, reaching code execution on the host running Ray. Fixed in Ray 2.52.0; CISA KEV-listed 2026-08-17.

CVE-2025-62593; Ray's dashboard is defended against browsers by a User-Agent string check, and CISA now records the DNS-rebinding bypass as exploited

CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog on 2026-08-17, describing it as a code-injection flaw in Ray and noting that "Developers using Ray as a development tool may be exposed to this vulnerability exploitable through Firefox and Safari" (CISA KEV, catalogue version 2026.08.17). The underlying advisory is not new (the Ray project published it on 2025-11-26) but the exploitation determination is, and it changes the flaw's standing from a documented design weakness to something being used.

The design decision behind it is stated plainly by the project: Ray's dashboard exposes job-submission endpoints, including /api/jobs and /api/job_agent/jobs/, without authentication, and the guard against browser-originated requests is a heuristic on the User-Agent header. As the advisory puts it, "This vulnerability is due to an insufficient guard against browser-based attacks, as the current defense uses the User-Agent header starting with the string 'Mozilla' as a defense mechanism" (Ray project, 2025-11-26). That assumption holds only where the browser refuses to let a page set the header. Firefox and Safari implement the fetch specification and permit it; Chrome does not, which the advisory notes is the result of a long-standing bug that puts Chrome out of spec, so the browser most likely to be non-compliant is the one that happens to be safe.

The reason this reaches hosts that no firewall would consider exposed is DNS rebinding. The attacker does not need network reach to the Ray dashboard; the victim's browser has it. A developer running Ray locally who visits a malicious page (or is served a malicious advertisement, which the advisory calls out explicitly) gives that page a path to resolve an attacker-controlled hostname to a loopback or internal address, overwrite the User-Agent, and POST a job to the dashboard, which executes it. The advisory further states the same browser-as-intermediary path can be turned against network-adjacent Ray instances, so a single developer workstation reaches cluster nodes that were never meant to be addressable from outside. The fix is Ray 2.52.0, which the project notes also, finally, adds an authentication feature; one that is disabled by default, so upgrading alone leaves the endpoints open to anything that can already reach them.

Detection, telemetry class first. The observable sequence is a browser process making a local or internal HTTP request it has no business making. In DNS and resolver telemetry, the rebinding step is a hostname whose answer changes to a loopback or RFC 1918 address within a short TTL window on a host that has just browsed externally, the classic signature, and the one that fires before anything reaches Ray. In the Ray dashboard's own access logs, the anchor is a POST to the job-submission endpoints carrying an Origin or Referer that names an external site rather than local tooling. In host process and network telemetry, correlate an outbound browser session with a subsequent connection to the dashboard port (8265 by default) from that same browser process, and then with Ray spawning a job-worker process tree that no scheduler or CLI invocation accounts for. Triage: legitimate dashboard traffic comes from the Ray CLI, a notebook kernel or an IDE extension, local, non-browser processes with no cross-origin headers, and job submissions that correlate with a developer's own session. Browser-originated POSTs to those endpoints have no benign equivalent, and the DNS answer that recently pointed elsewhere is the corroborating half.