The deadline has passed. On August 17, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog and gave federal civilian agencies until August 20 to remediate — a three-day window, among the tightest CISA has ever issued. The short clock was not improvisation. Binding Operational Directive 26-04, published in June, revoked CISA's older patching rules and moved agencies onto a risk model that can compel action in as few as three days.
Ray is the Python-native framework used to scale AI and machine learning workloads across fleets of CPUs and GPUs. It has more than 42,000 GitHub stars and underpins a great deal of training and inference infrastructure. CVE-2025-62593 carries a CVSS 4.0 base score of 9.4 — critical — and is classified under both CWE-94, code injection, and CWE-352, cross-site request forgery. Every release below 2.52.0 is affected. Version 2.52.0, shipped November 26, 2025, is the fix.
What makes the listing unusual is not the score. It is the target. Ray is server infrastructure. This vulnerability is exploited against laptops.
A header check, and then the browser
Ray's dashboard and job submission API — the `/api/jobs` and `/api/job_agent/jobs/` endpoints — are designed to execute code submitted to them. That is the product. To keep a random web page from reaching a Ray instance on a developer machine, Ray checked whether the request's `User-Agent` header began with "Mozilla," and rejected it if so.
The Fetch specification permits scripts to set that header, and Firefox and Safari implement the spec faithfully. Chrome is not a viable path, ironically, because a long-standing Chromium bug leaves it out of spec. A bypassable header check alone would not be enough; the same-origin policy still stands between a page and a service on localhost. Researchers chained it with DNS rebinding, a two-decade-old technique that makes a browser treat an attacker-controlled hostname and a local address as the same origin. The result, per the maintainers' advisory: a developer running Ray locally who visits a malicious page — or is served a malicious ad — can have shell commands executed on their machine with no further interaction.
The advisory, GHSA-q279-jhrf-cc6v, is unusually blunt about the root cause. "Due to the longstanding decision by the Ray Development team to not implement any sort of authentication on critical endpoints, like the /api/jobs & /api/job_agent/jobs/ has once again led to a severe vulnerability that allows attackers to execute arbitrary code against Ray," it reads. "This time in a development context via the browsers Firefox and Safari." Credit went to Oligo Security's Avi Lumelsky, who theorized the fetch bypass, and Jonathan Leitschuh, then at Socket, who built the rebinding chain.
The vendor is not disputing this one
Anyscale has argued before that certain Ray issues are design, not defect. In November 2023 it declined to fix CVE-2023-48022 — the missing-authentication flaw behind ShadowRay — calling the absence of built-in authentication "a long-standing design decision based on how Ray's security boundaries are drawn," and calling it "not in our opinion a vulnerability, or even a bug." The reasoning: Ray "is designed to provide arbitrary remote code execution (RCE) as-a-service," so the security boundary belongs outside the cluster. That CVE remains disputed and unpatched.
CVE-2025-62593 is a different case. Anyscale published its own response on August 19, two days after the KEV listing. "The listing is accurate and if teams are still running a version of Ray below 2.52.0, we recommend upgrading Ray," wrote Anyscale's Emre Saglam. This flaw was reported privately, fixed, and published with a full writeup. Anyscale also pushed the token authentication 2.52.0 introduced — still opt-in — saying it is "actively working toward making token authentication the default rather than an opt-in."
The exploitation timeline should worry people. Bitsight reported in March 2026 that RondoDox DDoS botnet operators added CVE-2025-62593 to their toolkit around November 24, 2025 — two days before it was published — because a proof of concept was already available. Separately, Oligo's ShadowRay 2.0 research tracked attackers hijacking exposed Ray clusters through the older disputed CVE to mine cryptocurrency on NVIDIA GPUs. Oligo's scans found "over 200,000 Ray servers remain exposed to the internet," with compromised clusters worth an estimated $4 million a year in stolen compute.
Why It Matters
Two assumptions are failing at once. The first is that the frameworks orchestrating frontier training runs are held to the standard of the models they train. They are not. Ray's browser defense was a string comparison.
The second is the trusted-network model. Anyscale's position is coherent: a distributed execution engine exists to run arbitrary code, so it cannot be secured from the inside, and the perimeter belongs outside it. But a perimeter that depends on every operator drawing it correctly, forever, is one that 200,000 internet-facing servers have already failed. And CVE-2025-62593 punctures the model from a different angle — it does not require anyone to misconfigure anything. An instance on a laptop, bound exactly as recommended, was reachable through a browser tab. Nine months passed between the patch and CISA's escalation, all of it on the least-inventoried surface most organizations own.
What to Watch
Check the version first: `ray --version` or `pip show ray`. Anything below 2.52.0 needs upgrading, and later is better; Anyscale notes further browser-boundary hardening since. Enable token authentication in development as well as production, since local development is where this was exploitable. Audit for `--dashboard-host=0.0.0.0` in cluster configs, container images, and Helm charts, workstations included. And look where inventory tools do not: lockfiles that will reinstall the vulnerable release after you patch, CI runner images, base layers, notebook environments. Where patching is impossible, CISA's guidance is to stop exposing Ray dashboards and APIs to untrusted networks, and discontinue use if no mitigation exists.
Watch whether token auth becomes the default rather than a checkbox. Until it does, the trusted-network assumption remains Ray's only real boundary — and the KEV catalog now holds a Ray entry that argues against it.
“The listing is accurate and if teams are still running a version of Ray below 2.52.0, we recommend upgrading Ray.”— Emre Saglam, Anyscale