On 17 August 2026 CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog and gave federal agencies until 20 August to act. The flaw is in the Ray dashboard, and it was published in November 2025, so this is an old bug with a new exploitation signal.
The attacker does not need network access to your Ray cluster. They need you, or a developer on your team, to load a malicious page or ad in Firefox or Safari while Ray is running.
What's affected
The ray Python package before 2.52.0. The fix is 2.52.0. NVD scores it 9.4 on CVSS 4.0 and 8.8 on CVSS 3.1, and the weaknesses are CWE-94 (code injection) and CWE-352 (CSRF).
The Ray dashboard tried to block requests that come from a browser by checking whether the User-Agent header starts with "Mozilla". The fetch specification lets page JavaScript change that header in Firefox and Safari, so the check fails. Add DNS rebinding, which lets a hostile site point its own domain at your local or internal address, and the page can send requests to /api/jobs and /api/job_agent/jobs/ as if it were on your network. A job submission is a shell command. According to the advisory, Chrome is not affected because of an out-of-spec browser behavior.
The Cloud Security Alliance note on the KEV addition says the RondoDox botnet added a proof of concept for this bug two days before the November 2025 disclosure.
How to check if you're exposed
pip show ray | grep -i '^version'
ray --version
# is a dashboard listening, and on which address?
ss -ltnp | grep 8265
Port 8265 is the default dashboard port. If it listens on 0.0.0.0 or a routable address, anything on that network can reach it. Also search container images and CI runners, since Ray often arrives as a transitive dependency:
docker run --rm <image> pip list 2>/dev/null | grep -i '^ray '
Then check dashboard or proxy logs for POST requests to /api/jobs from unexpected sources.
What to do now
- Upgrade to Ray 2.52.0 or later, on laptops, notebooks, clusters and base images.
- Turn on the token authentication that 2.52.0 added. It is off by default, so upgrading alone does not enable it. The advisory does not name the setting, so use the Ray documentation for your version.
- Bind the dashboard to localhost unless you need remote access, and put anything shared behind a VPN or an authenticating proxy.
- Keep Ray hosts away from network segments with unrestricted web browsing.
- If an instance was reachable before the upgrade, treat it as possibly compromised and review submitted jobs.
How this could have been avoided
- Authentication on the dashboard from day one. The job API accepted any request that passed a header check. A token requirement would have stopped a rebinding page that cannot read the token.
- Do not use headers as an access control.
User-Agentis set by the client. Origin and Host validation, plus real authentication, are the controls a browser cannot talk its way past. - Validate the Host header. DNS rebinding works when a server answers requests addressed to an attacker's hostname. Rejecting unknown Host values breaks the technique.
- Separate browsing from compute. Developer machines with a browser and a local Ray node form the exact pair this attack needs.
Why it matters
Developer tooling often ships with no authentication because it expects to live on localhost. DNS rebinding turns that assumption into a hole, because a browser tab can reach anything your machine can.
Try it yourself
Run pip freeze | grep -i ray on a laptop that runs notebooks, then check which port the dashboard binds to.
Click through it at your own pace, or open it full screen.
Quick check
Why does upgrading to 2.52.0 not fully close the exposure?
Token authentication arrived in 2.52.0 but is disabled by default. You still need to enable it and restrict where the dashboard listens.
Why does the User-Agent check fail?
Firefox and Safari allow page JavaScript to change the header, so an attacker can send a value that does not start with "Mozilla".
