CISA gave federal agencies three days to patch a bug in Ray. Three days is the shortest window they hand out, and they only use it when attackers are already exploiting something in the wild. The flaw is CVE-2025-62593, scored 9.4 on CVSS v4, and it affects every Ray version before 2.52.0.

The severity score is not the interesting part. Where the attack lands is. Most Ray security coverage over the past two years has been about clusters sitting on public IPs with no authentication. This one goes after the machine under your desk.

How it works

Ray exposes a dashboard and a jobs API. Before 2.52.0, the protection stopping a random website from talking to that API was a check on the HTTP User-Agent header. If the string started with Mozilla, Ray assumed a browser was calling and refused. That header is not a security control. It can be changed.

Pair a weak check with DNS rebinding and you get remote code execution. Rebinding is old and boring and still works. An attacker controls a domain, serves you a page, then re-resolves that domain to 127.0.0.1. Your browser keeps the tab open and keeps treating it as the same origin. The page can now talk to whatever is listening on your loopback interface. If Ray is running locally, the page submits a job. That job is arbitrary Python on your machine, running as you.

You do not have to click anything unusual. Loading a page that serves a malicious ad is enough. Firefox and Safari users had it worse because of how those browsers handle DNS caching.

Operators of the RondoDox DDoS botnet folded the exploit into their toolkit within days of public disclosure. That is the tempo now. Assume anything with a working proof of concept is weaponised inside a week.

Localhost is not a security boundary

Bind to 127.0.0.1, skip the auth setup, move on. Every developer has done this. The reasoning feels airtight: nothing outside this machine can reach it.

DNS rebinding has been breaking that reasoning for over twenty years. Your browser is an attacker-influenced HTTP client that already lives inside your perimeter. Anything listening on loopback without authentication is one malicious page away from becoming an endpoint the internet can call.

Ray is the one with a CVE this week. Go look at what else your team runs locally. Jupyter without a token. MLflow tracking servers. Airflow webservers in dev mode. Spark UIs. The Docker daemon on port 2375. That internal admin panel someone stood up for convenience and never locked down. Same shape, same exposure.

The correct defence is Origin and Host header validation. Origin is set by the browser and page JavaScript cannot forge it. Host validation defeats rebinding directly, because the rebound request still carries the attacker controlled hostname.

What to do this week

Upgrade Ray to 2.52.0 or later. Check developer laptops and CI images, not just cluster nodes.
Grep your setup scripts and Makefiles for services bound to localhost with auth disabled. Write down every one you find.
Turn on tokens for local ML tooling. Putting one in a shell profile takes two minutes.
Treat developer machines as part of your credential blast radius. If a laptop holds a cloud token with write access to production, an RCE on that laptop is a production incident.
Put the check in your onboarding docs so the problem does not regrow next quarter.

The bigger pattern

ML infrastructure has been getting a pass on security expectations we apply to everything else. Ray, Airflow, MLflow and the rest grew up as research tools where the threat model was roughly "everyone on this network is a colleague." They are load-bearing production systems now, and a lot of the time they are running on the same laptop as an open browser with fourteen tabs.

If you build with these tools, the security review is part of the build. Not a later phase.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!