Loading today’s stories
Security1 distinct publisher3 min readUpdated
Ray never authenticated its job endpoints, and the User-Agent check meant to keep browsers out is spoofable in Firefox and Safari. DNS rebinding does the rest.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
The Ray project's long-standing decision not to authenticate its job-submission endpoints is now reachable from an ordinary web browser [3]. CVE-2025-62593 means an ML engineer running a local Ray node can be handed remote code execution by visiting a malicious page or being served a malvertisement [1][10].
The exposed endpoints are `/api/jobs` and `/api/job_agent/jobs/`, which carry no authentication [3]. The only barrier against browser-driven abuse is a check that rejects any request whose `User-Agent` header starts with the string "Mozilla" [4]. The code's own comment concedes the heuristic is "very weak," resting on the assumption that `fetch` and XHR cannot alter the User-Agent header [5].
That assumption is wrong for two of the three major browsers. The fetch specification permits the User-Agent header to be set to a different value, and both Firefox and Safari honor it [6]. Chrome is not vulnerable, according to the advisory, only because of a bug that puts it out of spec with fetch [7]. The defense is not authentication; it is a string prefix an attacker controls.
The remaining obstacle is reaching a service bound to the developer's own machine. DNS rebinding solves that, and the advisory notes it is trivially performed with tooling such as nccgroup's Singularity [8]. Chained together, an attacker spoofs the User-Agent, rebinds DNS to the local Ray dashboard on TCP port 8265, and invokes the jobs API to execute code [8][9]. The published proof of concept pops a calculator, but the report states the payload can be modified for other operating systems and implementations [11].
This is not a lab-only concern. The researcher reports getting the attack to work repeatedly on macOS across multiple residential networks around Seattle [12]. Some corporate networks may block DNS rebinding, though the advisory expects not many will [13]. The failure mode is the developer laptop that runs `ray start --head` and then opens a browser tab, which is the normal workflow.
The advisory is blunt that this refusal to authenticate has "once again" produced a severe vulnerability, framing it as a recurring consequence of a design choice rather than a one-off bug [14]. A User-Agent prefix is a filter, not a credential, and any control that an attacker's own client can set will eventually be set.
What to watch: the full proof of concept was scheduled to go live at the time of disclosure [15]. Operators running Ray in development should treat the dashboard port as internet-adjacent even when it is bound to localhost, and should not assume the "Mozilla" guard protects Firefox or Safari users. The durable fix is authentication on the job endpoints; until Ray ships that, the mitigation is network isolation of port 8265 and not browsing while a head node is up.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
CVE-2025-62593 is a critical remote code execution vulnerability in Ray, exploitable via the Firefox and Safari browsers through a DNS rebinding attack.
Developers working with Ray as a development tool can be exploited via this critical RCE vulnerability.
The Ray development team has a longstanding decision not to implement any authentication on critical endpoints, including /api/jobs and /api/job_agent/jobs/.
The current defense against browser-based attacks checks whether the request's User-Agent header starts with the string 'Mozilla' and rejects it if so.
The is_browser_request code comment describes the heuristic as 'very weak' and assumes that fetch and XHR cannot alter the User-Agent header.
The defense is insufficient because the fetch specification allows the User-Agent header to be modified, and in Firefox and Safari the fetch API allows it to be set to a different value.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Strong first-party advisory, single publisher
The claims rest on a first-party GitHub Security Advisory (GHSA-q279-jhrf-cc6v) and its CVE-2025-62593 database mirror, including the reproduced vulnerable code, a clear fetch-specification explanation, and a working PoC. That is solid, technically detailed evidence, but it is confined to one publisher (GitHub) with no CVSS score, patch detail, or independent confirmation, and the full PoC was still pending at disclosure.
No real-world adoption/exploitation data
The only real-world signals are the disclosure itself and the researcher's self-reported repeated testing on their own macOS machines around Seattle. There is no data on affected install base, uptake of any fix, or in-the-wild exploitation, so real-world adoption/impact cannot be measured.
Slightly overstated vs. demonstrated impact
The technical claims are well-evidenced, but the 'critical' framing modestly outruns demonstrated real-world impact: exploitation requires a developer running Ray locally, using Firefox or Safari (Chrome is stated not vulnerable), visiting attacker content, and a DNS-rebinding attack that may need several attempts and that some networks block, with no evidence of in-the-wild use.
Researcher-disclosure incentive, non-commercial
The single source is a security researcher's advisory (attributed in the payload 'By JLLeitschuh') with a mild incentive to emphasize severity and to editorialize about Ray's maintainers ('once again'), plus an attacker-favorable expectation that few corporate networks will block the technique. It is a standard, non-commercial responsible-disclosure advisory, so the biasing incentive is moderate rather than strong.
Consistent first-party sourcing, limited breadth
Confidence is supported by two consistent GitHub-hosted renderings (project advisory and CVE database) with code-level detail, but tempered by single-publisher sourcing, the full PoC being pending at disclosure, and the absence of third-party verification, CVSS, or patch information.
product
CISA gives federal agencies three days to patch Ray, the framework under your ML pipelines1 distinct publisher
invest
Mozilla's pitch against Gemini-wired Chrome is an off switch and a search deal with Exa2 distinct publishers
security
Thirteen new Metasploit modules close the patch window on SonicWall SMA1000, Ghost CMS and Langflow1 distinct publisher
product
iOS 27 lands in September, and it absorbs features apps currently sell1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.