Ray Guarded Its Job API by Checking Whether Your Browser Said "Mozilla"
CVE-2025-62593 hit its federal patch deadline today. Upgrading takes a minute. The habit it exposes, trusting localhost, runs through most of the AI stack you have listening on a port right now.
The code that kept web browsers away from Ray's job-submission endpoint was one line:
return req.headers["User-Agent"].startswith("Mozilla")
Directly above it in the Ray source sits a docstring that reads like a confession. "This heuristic is very weak, but hard for a browser to bypass." Half of that sentence was correct. It was very weak. The other half was a guess about what browsers let JavaScript do, and in Firefox and Safari the guess was wrong. The fetch specification allows a script to set the User-Agent header. Set it to the string Other and the guard opens.
That is CVE-2025-62593, rated 9.4 under CVSS 4.0, and CISA gave federal agencies until today, August 20, to fix it.
A three-day deadline is the tell
CISA added the flaw to the Known Exploited Vulnerabilities catalog on Monday, August 17, moving its assessment from "proof of concept exists" to "actively exploited." Federal Civilian Executive Branch agencies got three days. Most KEV entries carry two or three weeks.
Ray is not an obscure package. It is the distributed compute framework underneath a large share of Python-native training and serving work, with more than 43,500 stars on GitHub. If you have run a Ray cluster, you have almost certainly also run ray start --head on your laptop, opened the dashboard on port 8265, and left it running while you went back to reading docs in another tab.
That other tab is the attack.
Here is my position, and it is not really about Ray. The patch is trivial and you should apply it today. The design decision underneath it is not trivial, it is still in place, and it is the same decision made by nearly every AI development tool that binds a port on your machine. Ray's maintainers wrote the reason into the advisory themselves: "the longstanding decision by the Ray Development team to not implement any sort of authentication on critical endpoints, like the /api/jobs and /api/job_agent/jobs/." Version 2.52.0 finally ships token authentication, and it ships disabled by default. Patching does not turn it on. You do.
How a web page reaches into your laptop
The mechanism is DNS rebinding, and it is worth understanding once because it applies to everything on your loopback interface.
The same-origin policy, the rule that stops evil.com from reading your bank tab, keys on the origin: scheme, host name, port. The host name. Not the IP address behind it.
So an attacker registers a domain, points it at their own server with a very short TTL, and serves you a page. Your browser trusts that page for that host name. Then the DNS record flips to 127.0.0.1. Your browser re-resolves, the host name has not changed, so the origin has not changed as far as the policy is concerned, and the JavaScript on the page keeps its permission to read responses. Only now the requests land on your machine. The browser is the confused deputy: it has network access you do not want to give the page, and it uses that access on the page's behalf.
Wire that to Ray and the payload is a POST to /api/jobs/ with an entrypoint field. The entrypoint is a shell command. Ray runs it. The public proof of concept pops the calculator, because that is the polite version.
Two details make this sharper than the usual local-service bug.
The attack does not need you to click anything on the attacker's site. The CVSS vector records user interaction as Passive, which in plain terms means visiting the page is enough. The advisory names malvertising as a delivery path, so "do not visit sketchy sites" is not the control you think it is.
And the browser can pivot past your laptop. The advisory notes the same technique reaches "network-adjacent instances of Ray" inside a private corporate network, using your browser as the intermediary. Your machine does not have to be running Ray for your machine to be the way in.
The part that made me laugh, then stop laughing
Chrome is not vulnerable to this. Not because Chrome shipped a defense, but because a Chromium bug prevents scripts from setting User-Agent, putting Chrome out of spec with fetch. The advisory says it plainly: "Chrome is not vulnerable, ironically, because of a bug."
So the population of protected developers was defined by a browser defect rather than by anyone's security model. That is a fair summary of where local AI tooling security sits in August 2026.
Browsers are working on the real fix. Chrome is rolling out Local Network Access prompts, which would break rebinding attacks against loopback in general. The advisory is careful here, and so am I: a previous version of this effort, Private Network Access, was rolled back once already. Nineteen years after DNS rebinding was described, the browser layer is still not a control you can plan around.
Put this into practice
The Ray-specific work is fifteen minutes. The inventory work is the part with lasting value.
1. Find every Ray install, not just your clusters. Workstations and CI images are the exposure here, and they are the ones nobody tracks.
pip show ray | grep -i version
pip list 2>/dev/null | grep -i "^ray "
Then run the same check inside your build images. A pinned ray==2.4x in a two-year-old Dockerfile is the most likely place you find this.
2. Upgrade to 2.52.0 or later.
pip install --upgrade "ray>=2.52.0"
3. Turn on the authentication that shipped off. This is the step people will skip, because the CVE is closed without it. Follow the token auth docs and set it up for anything longer-lived than a scratch session. If your team decides not to, decide it out loud rather than by default.
4. Inventory what else answers on loopback. This is the generalizable move. Open a terminal and look:
lsof -nP -iTCP -sTCP:LISTEN | grep -E "127.0.0.1|\*:"
On a working ML machine you will find more than you expect. Jupyter, MLflow, TensorBoard, a vLLM or Ollama server, a vector database, two or three agent frameworks with debug UIs, and whatever you started last week and forgot. For each one, ask a single question: if a web page could send requests to this port, what could it make happen? Anything that answers "run a command," "read a file," or "call a model with my key" needs authentication, not a heuristic.
5. Split your browsing from your building, at least a little. A separate browser profile for casual reading costs nothing and shrinks the window where an ad on a news site meets a dashboard on 8265.
I would put step four on a calendar rather than treating it as a one-time cleanup. The list of things listening on your loopback grows every time you try a new agent framework, and none of them ask permission.
Honest limitations
I want to be careful not to oversell the panic, because a few numbers cut against it.
The EPSS score for this CVE is 0.369%, the 29th percentile. That model estimates the chance of exploitation in the next 30 days, and it does not rate this one highly, which reflects that the attack targets individual developers rather than internet-exposed servers. CISA published no details about how the exploitation it cited actually happened, so the KEV listing is an assertion you either accept or do not.
The strongest exploitation evidence is secondhand and older. BitSight reported in March 2026 that operators behind the RondoDox DDoS botnet had folded this vulnerability into their toolkit two days before public disclosure on November 26, 2025. Having something in an arsenal is not the same as having used it against you, and the more concrete Ray campaign in the wild, ShadowRay 2.0, targets unpatched internet-facing clusters for GPU cryptomining rather than developer laptops.
This specific vector needs Firefox or Safari. Chrome and Chromium-derived browsers are unaffected by the header bypass. Some corporate DNS resolvers block rebinding, though the researcher who built the proof of concept reported it working across multiple residential networks and noted that "some corporate networks may block DNS rebinding attacks, but likely not many."
And credit where it belongs: this is a good advisory. It names the flawed assumption, publishes the vulnerable code, links the exact fix commit, credits Avi Lumelsky for the fetch bypass and Jonathan Leitschuh for the rebinding chain and disclosure, and admits the auth-by-default gap rather than burying it. Plenty of vendors would have written three sentences about "an issue affecting certain configurations."
What I keep thinking about
The heuristic had a comment on it. Someone wrote down that the defense was weak, shipped it anyway because the alternative was designing authentication for a tool people run on their own machines, and it held for a while. It was not negligence. It was a reasonable trade in a world where localhost felt private.
Localhost has not been private for a long time, and the AI tooling boom put a dashboard on it. Every agent framework with a web UI, every local inference server with an HTTP API, every notebook, made the same bet Ray made, and most of them have not had a researcher point a rebinding rig at them yet.
Go run the lsof command. Whatever comes back is your actual attack surface, and I would bet you have never written it down.
Sources: GitHub Security Advisory GHSA-q279-jhrf-cc6v, CISA Known Exploited Vulnerabilities catalog, CISA alert, August 17, 2026, The Hacker News, Ray token authentication docs, Chrome Local Network Access.