THE FACTS
● CVE-2025-62593 — CVSS 4.0 score 9.4, code injection (CWE-94) with CSRF (CWE-352).
● Affects: all Ray versions before 2.52.0.
● Fix: upgrade to Ray 2.52.0 or later. Advisory GHSA-q279-jhrf-cc6v.
● Status: CISA KEV as of 17 August 2026, federal remediation deadline 20 August under BOD 26-04.
Why this one is not like other critical CVEs
Ray is the Python-native distributed computing framework for scaling AI and ML workloads — over 43,500 GitHub stars, nearly 7,900 forks, used by Amazon, Apple and OpenAI. It is infrastructure, and most people assume infrastructure flaws threaten servers.
This one threatens laptops.
THE ATTACK PATH
A developer has Ray running locally. They open Firefox or Safari and visit a page — or simply load a page carrying a malicious advert. Through DNS rebinding, that page reaches the local Ray instance and executes code on the machine.
No login. No inbound network exposure. No action beyond browsing.
The underlying weakness is almost quaint. Ray's dashboard and API defence relied on checking whether the HTTP User-Agent header began with "Mozilla" — a value any client can set. Combined with DNS rebinding, that check is not a control at all. The relevant endpoints are the job-related ones, which accept requests capable of launching code.
Ray's own maintainers said the quiet part in their November 2025 advisory: a longstanding decision by the development team not to implement authentication on critical endpoints had once again produced a severe vulnerability. "Once again" is doing real work in that sentence.
The timeline is worse than the flaw
| Date |
Event |
| 24 Nov 2025 |
RondoDox botnet begins attempting exploitation, per Bitsight |
| 26 Nov 2025 |
CVE published — two days after exploitation started |
| Nov 2025 |
Ray 2.52.0 ships with the fix |
| Mar 2026 |
Bitsight publishes the RondoDox research |
| 17 Aug 2026 |
CISA changes SSVC from proof-of-concept to active, adds to KEV |
| 20 Aug 2026 |
Federal remediation deadline. Three days |
Botnet operators were tracking public vulnerability research rather than waiting for a CVE number. That is now the normal case, not an outlier, and it means "we patch on CVE publication" is a policy with a built-in gap. Activity has also been linked to ShadowRay 2.0.
Nine months passed between the patch shipping and CISA escalating. Anything unpatched today has been exposed that entire time.
Where Ray is hiding
The upgrade is trivial. Finding every install is not. Ray arrives as a transitive dependency in ML tooling far more often than teams realise.
| Check |
Why it gets missed |
| Developer workstations |
The actual target here, and the least inventoried surface you own |
| CI/CD runners |
Ephemeral, so nobody scans them, but they rebuild from pinned versions |
| Container base images |
A patched app on an unpatched base image is still vulnerable |
| Kubernetes workloads |
Ray clusters often predate whoever now owns the namespace |
| Dependency lockfiles |
A lockfile will happily reinstall the vulnerable version after you patch |
| Cloud data-processing clusters |
Managed services may pin an older Ray than you assume |
Quick check on any machine: pip show ray or python -c "import ray; print(ray.__version__)". Anything below 2.52.0 needs upgrading. Then rebuild images and confirm your lockfiles do not pull it back.
Where patching is not immediately possible, CISA's guidance is to stop exposing Ray dashboards and APIs to untrusted networks, and to discontinue use where no mitigation exists.
The pattern worth noticing
This is the second AI-infrastructure story in a week where the flaw was not clever. Copilot Autofix and the Snowflake workflow injection came down to untrusted input reaching a shell. This one comes down to no authentication on an endpoint that runs code, protected by a header string anyone can spoof.
AI tooling has been built fast, and a lot of it carries the security posture of an internal prototype that got 43,000 stars. The frameworks scaling frontier training runs are not, as a class, held to the standard of the models they train.
For anyone building on this stack, the practical implication is unglamorous: treat ML infrastructure like any other production dependency. Inventory it, patch it, and do not assume that because it runs locally it is not exposed.
FAQ
What version fixes CVE-2025-62593?
Ray 2.52.0 or later. The advisory is GHSA-q279-jhrf-cc6v.
I only run Ray locally. Am I safe?
No — local is the target. The attack reaches your local Ray instance through your browser via DNS rebinding while you browse normally in Firefox or Safari.
Does it need Firefox or Safari specifically?
Those are the browsers named in CISA's listing and the vendor advisory. Do not read that as other browsers being safe; read it as those being the confirmed paths.
How long has this been exploited?
Bitsight found the RondoDox botnet attempting exploitation from 24 November 2025, two days before the CVE was published. CISA formally reclassified it as active on 17 August 2026.
What if I cannot patch right away?
Do not expose Ray dashboards or APIs to untrusted networks, and check whether Ray needs to be running on developer machines at all when not actively in use. CISA advises discontinuing use where mitigation is unavailable.
Does this affect models trained with Ray?
No. This is a flaw in the framework's API surface, not in anything it produces. Trained artefacts are unaffected.