Ray Framework Vulnerability Lands in CISA's KEV List

CVE-2025-62593 hits Ray below 2.52.0, scores 9.4, and can be triggered from a web page via DNS rebinding. Federal agencies got three days.

Cecilia Iona
Cecilia Iona
Senior Editor, AI & Product
19 August 20261 min read

CISA added a Ray framework vulnerability to its Known Exploited Vulnerabilities catalog on 17 August 2026 and gave federal agencies until 20 August to fix it. Three days is not a normal remediation window. It is what CISA issues when exploitation is already happening and the attack is cheap.

The bug is CVE-2025-62593, a code injection flaw affecting Ray versions before 2.52.0, carrying a CVSS 4.0 score of 9.4. Ray is the open-source distributed compute framework a large amount of machine learning training, batch inference, and general parallel Python work runs on.

What the flaw actually does

The vulnerability lives in how Ray handles its HTTP API endpoints, including /api/jobs and /api/job_agent/jobs/. Those endpoints exist to let you submit work to a cluster. An attacker who can reach them can submit arbitrary code and have Ray execute it, which is the whole attack.

The reason this is being treated as urgent rather than as a normal misconfiguration is the delivery route. According to The Hacker News, the flaw can be triggered through a web browser using a DNS rebinding attack, with Firefox and Safari named. The Register covered the same three-day federal deadline.

DNS rebinding is the part worth slowing down on, because it breaks an assumption most people hold without examining it.

Why "it's only on localhost" stops being true

The mental model most of us carry is that a service bound to 127.0.0.1 is private. Nothing on the internet can route to it, so nothing on the internet can talk to it.

DNS rebinding gets around this by using the victim's own browser as the router. A page you visit is served from a domain whose DNS record has a very short time to live. The browser loads the page, script on it makes another request to the same domain, and by then the DNS answer has changed to 127.0.0.1. From the browser's perspective this is still the same origin, so its usual restrictions do not fire. The request lands on whatever is listening on your loopback interface.

So the exposure is not "did I put my Ray dashboard on the public internet". It is "was Ray running on this machine while a browser tab was open". For anyone who started a local Ray instance to test something and left it running, that is a considerably wider door than it looks.

What to do

The fix is a version bump, and it is not complicated:

  1. Upgrade to Ray 2.52.0 or later. That is the fixed release.

  2. Rebuild any container images that pulled an older Ray in as a transitive dependency, since the image will keep shipping the vulnerable version until you do.

  3. Check that your package manager has not cached or pinned an older release. Lockfiles are the usual culprit here.

  4. Look for Ray processes still listening on developer machines, not just on cluster nodes. The browser vector makes laptops in scope.

  5. If a Ray instance was reachable during the exposure window, treat it as a possible execution, not just a possible exposure. Check what ran.

Step 4 is the one that gets skipped. Infrastructure inventories catch clusters. They rarely catch the ray.init() somebody ran in a notebook in June.

The broader pattern

AI infrastructure keeps arriving as developer tooling that quietly becomes production. Ray, vector stores, model servers, and local inference runtimes all tend to ship with defaults tuned for a trusted single-user machine, then get deployed where those assumptions do not hold. A framework designed to accept and execute submitted code is doing exactly its job right up until the boundary around it is wrong.

This is the same shape as the risk in running an AI model locally, where the security posture is inherited from tools that never expected to be exposed. It is also why an AI incident response plan needs to name who checks the CISA catalogue and how often, because a three-day deadline does not leave room to work that out from scratch.

If you keep a list of the components your stack depends on, that list is what turns an advisory into a ten-minute check instead of an afternoon. If you do not keep one, the AI risks worth tracking start with the ones you cannot enumerate.

FAQ

Which Ray versions are affected?

Everything before 2.52.0. Upgrading to 2.52.0 or later is the remediation CISA and the project point to.

Am I exposed if Ray only ran on my laptop?

Possibly, and that is the unusual part of this one. The DNS rebinding vector means a browser tab on the same machine can reach a service bound to loopback, so a local-only Ray instance is not automatically safe.

What is the CISA KEV catalog?

A published list of vulnerabilities with confirmed exploitation in the wild. US federal agencies get binding remediation deadlines from it. For everyone else it works as a decent triage signal: presence on the list means the exploit exists and is being used, not that it is theoretically possible.

How did this land?

About the author

Cecilia Iona
Cecilia Iona

Senior Editor, AI & Product

Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.