SURIQ
Ray, the AI compute framework that trains and serves machine-learning models at some of the largest technology companies, has shipped for years on one assumption: whoever runs it will lock down the network themselves. That assumption just produced its second actively exploited path to remote code execution in under two years. On August 18, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog. This one does not need an exposed cluster. It reaches a developer's own laptop through the web browser.
What CISA flagged, and how serious it is
CVE-2025-62593 carries a severity score of 9.4 out of 10 and affects every Ray release before 2.52.0. The Ray dashboard exposes job-submission endpoints, /api/jobs plus the related /api/job_agent/jobs/, that accept work without any login. An attacker who reaches those endpoints can run code on the host. The federal patch deadline is August 21, 2026, three days after the listing.
The gap in that timeline is the story. The flaw was disclosed and fixed on November 26, 2025 in Ray 2.52.0. CISA does not add anything to its exploited list until it sees real-world attacks, so the roughly nine months between the patch and the listing is the window when unpatched instances were being hit. If you upgraded last winter, you are fine. If Ray is still on an older build because it sits behind a firewall and felt internal, that feeling is now the exposure.
Why binding it to localhost did not protect anyone
Many developers run the Ray dashboard bound to 127.0.0.1 on port 8265 and treat it as private. It is not, once a browser is in the picture. The attack uses DNS rebinding, where a malicious website first points its own domain at its real server, then re-points that same domain at 127.0.0.1. The browser still treats the two answers as one origin, so it will send requests from the attacker's page straight to the developer's local Ray instance.
This is not unique to Ray. Any local dashboard the browser can reach without a token is reachable from a web page the developer visits: Jupyter notebooks, MLflow, TensorBoard, a bare model server. The lesson for a defender is blunt. A service listening on localhost is not an access control. If it answers the browser and asks for no credential, treat it as if it were on the public internet. We made the same point when a single web page turned an AI agent's trust in its own machine into a takeover.
A User-Agent header is not authentication
Ray did ship one guard on those endpoints, and it is worth studying as a mistake. The dashboard checked whether the incoming request's User-Agent header started with the string Mozilla, on the theory that browser requests are hard to forge and would be blocked by the browser's same-origin policy anyway. Both halves of that theory are wrong.
The fetch function in Firefox and Safari lets a script set the User-Agent header to anything, so the Mozilla check is passed for free. Chrome, by an accident of its own implementation, refuses to let scripts change that header, which left Chrome users incidentally safe and Firefox and Safari users exposed. Being saved by a browser bug is not a security control.
The deeper error is treating a client-controlled request header as a trust boundary at all. A header the attacker's own code writes proves nothing. This is the same class of mistake that cross-site request forgery defenses learned to drop years ago, and it keeps resurfacing in fast-moving AI tooling that was never built for a hostile browser tab. Langflow shipped a similar story when an auth-optional default handed any stranger admin and then code execution.
The pattern is bigger than one flaw
Ray's maintainers have long held that the framework's open-by-default behavior is a feature, safe inside a trusted network, and that isolation belongs outside the cluster. That position is defensible in a data center. It has not survived contact with how people actually deploy.
The older half of this story is CVE-2023-48022, the unauthenticated job-submission issue nicknamed ShadowRay, which Ray declined to patch on exactly that reasoning. Security firm Oligo reported in November 2025 that a campaign it calls ShadowRay 2.0 had turned that design into a self-propagating botnet: more than 230,000 internet-exposed Ray servers, compromised clusters mining cryptocurrency, stealing source code and model weights, and scanning for the next victim. One cluster Oligo examined held over a thousand nodes. The attacker's code wore the names of ordinary Linux processes to stay hidden. The same fate has met other services that shipped unlocked by default and exposed servers pulled into botnets.
CVE-2025-62593 is what happened when that same auth-optional philosophy met the browser. CISA's listing is, in effect, a federal body overruling the secure-it-yourself stance: a patch deadline is not a configuration suggestion. It echoes other cases where an unauthenticated path stayed open because the vendor saw it as the operator's problem. Ray 2.52.0 finally ships optional token authentication, the control that would have shut both doors long ago.
Patch, then check whether you were already hit
The first action is the upgrade. Move every Ray installation to 2.52.0 or later and turn on the new token authentication. Do it on developer laptops too, not only production clusters, because the workstation is what this flaw targets.
-
Restrict the dashboard port, 8265, with firewall rules, and bind Ray to a specific network interface rather than
0.0.0.0. -
Run Anyscale's open-ports checker to find Ray instances you forgot were reachable.
-
Put an authenticating reverse proxy in front of the dashboard if you cannot upgrade right away.
Patching closes the hole. It does not tell you whether someone walked through first. Because CISA confirms active exploitation, assume the window mattered and hunt for it. Review the dashboard's job history for jobs nobody on your team submitted. Watch for outbound connections from Ray hosts to cryptocurrency mining pools, and for processes wearing familiar names like kworker that do not sit where the real kernel threads do. On a developer machine the same rule holds: a job that ran under your Ray instance when you did not start one is the sign that a page you visited did more than load.
Auth-optional defaults made Ray easy to adopt and easy to attack. The 2.52.0 release admits as much. The teams that come through this fine are the ones that stopped trusting a network perimeter to do a token's job.