Ray’s spoofable User-Agent guard becomes a browser-based RCE now on CISA’s KEV list

November 26, 2025. CVE-2025-62593 is published: a remote code execution in Ray, Anyscale’s distributed compute engine that underpins AI model training and inference. August 17, 2026. CISA adds it to the Known Exploited Vulnerabilities (KEV) catalog with confirmed active exploitation. August 20, 2026. The deadline imposed on US federal agencies to remediate.

Three days to patch. The reason for the urgency fits in one sentence: the defense meant to keep browsers off Ray relied on a User-Agent header that Firefox and Safari let you forge. It was never a defense.

A defense that was not a defense

Ray’s dashboard exposes critical endpoints, including /api/jobs and /api/job_agent/jobs/, which submit arbitrary work to the cluster. To stop a malicious web page from invoking them, the Ray team made a documented, long-standing choice: implement no authentication at all, and fall back on a heuristic filter.

That filter is literally a string comparison. The is_browser_request() function treats a request as coming from a browser if — and only if — its User-Agent header starts with the string “Mozilla”. A middleware then rejects POST and PUT requests from such “browsers” with a 405.

The underlying assumption, written plainly in the code, is that “fetch/xhr and friends cannot alter the user-agent.” That assumption is wrong. The fetch specification allows the User-Agent header to be modified, and Firefox and Safari implement it faithfully. Chrome escapes the exploit, ironically, because of a bug (Chromium issue 40450316) that keeps it out of spec.

The result: an attacker only has to set User-Agent: Other in a fetch call to slip past the filter and submit a job to the cluster.

DNS rebinding turns a page visit into code execution

Bypassing the User-Agent filter is not enough on its own: the request still has to reach the developer’s local port from a remote page. That is what DNS rebinding does.

The principle is well known. An attacker-controlled domain first resolves to a public IP, then — once the TTL expires — to a private address such as 127.0.0.1. The browser, still believing it is talking to the same host, sends the request to the visitor’s own machine. Tools like nccgroup/singularity automate the whole chain.

The full chain, described in the GitHub advisory, is disarmingly mundane. The developer starts Ray locally with ray start --head --port=6379, and its dashboard listens on port 8265. They then visit a compromised site — or get served a malicious ad (malvertising). The DNS rebinding runs, then a POST /api/jobs/ request with a User-Agent: Other header submits an entrypoint containing a shell command. That command executes with the developer’s privileges.

The researcher behind the report, Jonathan Leitschuh (JLLeitschuh), notes he reproduced the attack repeatedly on macOS from several residential networks. The demonstration payload merely opens the calculator; a real payload would exfiltrate keys, model weights, or cloud credentials.

No authentication, by design

The most instructive part of this incident is not the User-Agent check — it is the decision upstream. The GitHub advisory states it bluntly: the Ray team made the “longstanding decision” not to implement any authentication on critical endpoints, which “has once again led to a severe vulnerability.”

That “once again” points to a documented precedent. In early 2024, researchers showed that internet-exposed Ray clusters, unauthenticated by default, could be hijacked through the job submission API — the so-called ShadowRay campaign compromised production clusters to mine cryptocurrency and steal credentials.

CVE-2025-62593 is classified CWE-94 (code injection) and CWE-352 (CSRF). Severity is high: CVSS 4.0 at 9.4 (critical, vector AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) and CVSS 3.1 at 8.8. The fix, shipped in version 2.52.0, abandons the User-Agent filter.

KEV listing and the RondoDox signal

On August 17, 2026, CISA moved CVE-2025-62593 from “PoC” to “active exploitation” in its SSVC scoring, with the automatable flag flipped to “yes” and “total” technical impact. The same day it landed in the KEV catalog with a remediation deadline of August 20, 2026, under Binding Operational Directive 26-04.

The NVD record carries one more trace: it references BitSight’s analysis of the RondoDox botnet, added by CISA-ADP on August 17. That botnet, documented since May 2025, scans exposed services at scale and maintains a large exploit arsenal — 174 exploits counted by BitSight. The reference places Ray exploitation in the ecosystem of botnets that automate the compromise of misconfigured services.

For a CISO, the lesson is in the mechanics: the attacker needs no sophisticated interaction. A visit to a compromised site, an ad served through a third-party network, and a developer’s workstation executes code.

Why this lands on AI teams, not just developers

The victim profile is what makes this CVE worth a second look. Ray is used by ML engineers whose workstations hold cloud credentials, GPU-cluster access, and dataset paths — the keys to the entire training pipeline. A browser-based RCE that fires on a single malvertising impression turns one developer’s coffee break into a foothold in that pipeline. This is also why CISA’s SSVC flip to “automatable: yes” matters: the attacker needs no phishing, no stolen credential, and no user decision beyond a page visit.

Contrast that with the classic server-side RCE, which requires a reachable, exposed service. Here, the exposed surface is the developer’s browser tab — and no network ACL blocks that.

What to do

Remediation is simple and binary. Upgrade Ray to version 2.52.0 or later — that is the only complete fix. Commit 70e7c72780bdec075dba6cad1afe0832772bfe09 carries the patch.

Three complementary measures shrink exposure regardless of version:

• Never expose the dashboard (port 8265) to the internet. Keep it bound to 127.0.0.1 or behind a VPN.
• Put an authenticated reverse proxy in front of the dashboard if remote access is required. With no native authentication in Ray, that layer is an obligation, not an option.
• Block DNS rebinding at the source: a resolver or firewall that rejects answers pointing at private ranges (RFC 1918, link-local) neutralizes the vector for every application, not just Ray.

On Kubernetes, also check that the dashboard service is not published through an Ingress or a LoadBalancer service without access control.

Verdict

If you use Ray for development — local training, notebooks, distributed jobs — upgrade to 2.52.0 today. The exploitation window is real, automated, and the three-day federal deadline reflects active exploitation, not a theoretical threat.

If you run Ray clusters in production, the urgency lies elsewhere: with no native authentication, every exposed endpoint carries the risk. An authenticated reverse proxy and a minimal network surface are your real defenses — more than the package version.

The underlying signal: a “protection” built on a header the specification lets you forge is not a protection. When a security control reduces to a string comparison, treat it as a comment, not a guardrail.

References

• NVD — CVE-2025-62593 Detail, accessed August 18, 2026
• GitHub Security Advisory — GHSA-q279-jhrf-cc6v: Critical RCE Vulnerability against Ray Devs exploitable via Browser, published November 26, 2025
• CISA — Known Exploited Vulnerabilities Catalog, added August 17, 2026
• The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE, August 18, 2026
• BitSight — RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities, March 11, 2026
• nccgroup/singularity — DNS rebinding attack framework