The Vulnerability Your Vendor Says Isn't One

On Monday, CISA added a critical flaw in something called Ray to its Known Exploited Vulnerabilities catalog and gave federal agencies until this Friday, August 20, to fix it. Three days. That is a short fuse even by CISA standards.

Most executives have never heard of Ray. Most of their companies are running it.

Ray is an open-source framework for distributing AI and machine learning work across a lot of machines at once — the plumbing underneath model training and large-scale inference. It has been called "the Kubernetes of AI." Its GitHub project has more than 43,500 stars. If your company trains models, fine-tunes them, or runs meaningful AI workloads, there is a real chance Ray is somewhere in the stack, installed by a data science team that had no reason to file a ticket about it.

That is the ordinary part of this story. The interesting part is what it says about how risk gets onto — and stays off — your risk register.

Two Flaws, and Only One of Them Counts

The vulnerability CISA flagged this week is CVE-2025-62593, carrying a CVSS score of 9.4 out of 10. The mechanics are worth a plain-language pass, because they explain why "it's only on our internal network" is not the comfort it sounds like.

Ray's dashboard tried to block attacks launched from a web browser by checking whether the request's User-Agent header started with the word "Mozilla." That check turns out to be trivially bypassable. Combine that with a DNS rebinding attack — a technique that fools a browser into treating an attacker's server and a machine inside your network as the same origin — and a developer who simply visits a malicious website, or gets served a malicious ad, can have arbitrary code executed on their machine. Ray's maintainers noted the attack can be extended further, using the developer's browser as a go-between to reach other Ray instances sitting inside the private corporate network. Ray fixed it in version 2.52.0.

Now the second flaw, and the reason I'm writing about this at all.

There is an older Ray issue, CVE-2023-48022, that has never been patched. Not because nobody got around to it. Because Anyscale, the company behind Ray, has publicly taken the position that it is not a vulnerability or even a bug — it is a design decision. Ray's critical endpoints have no authentication on purpose, on the reasoning that Ray is meant to run only inside a strictly controlled network. Secure the perimeter around it, the argument goes, and there is nothing to fix.

The reasoning is defensible on its own terms. It is also, in practice, a bet that every customer will deploy the product exactly as intended. That bet has not paid off.

What Happens When Nobody Owns the Assumption

In November 2025, researchers at Oligo Security published findings on a campaign they named ShadowRay 2.0, in which attackers operating under the name IronErn440 exploited that same unpatched, disputed flaw to hijack Ray clusters worldwide. Oligo's scans found over 200,000 Ray servers exposed to the open internet — up from a few thousand when the firm first researched this in 2024.

What the attackers did with that access is the part to read twice. They used compromised clusters to scan for and infect the next set of clusters, producing worm-like self-propagation. They capped their compute usage at roughly 60 percent and hid GPU activity from Ray's own monitoring, specifically to avoid tripping anyone's alarms. They deployed a TCP exhaustion tool to launch denial-of-service attacks from victim infrastructure. And on the machines themselves, Oligo found production database credentials sitting in environment variables, cloud access tokens, proprietary model weights, and — on one server — a network mount holding 240 gigabytes of compressed source code, models, and datasets. One compromised cluster ran more than a thousand active nodes, compute Oligo priced in the millions of dollars a year.

Oligo's own summary of the underlying problem is the sentence I'd put in front of a board: "Disputed vulnerabilities create a dangerous gray area for defenders because they are not formally patched."

Your scanners look for versions to upgrade. When there is no version to upgrade to, the finding does not appear. Your compliance report comes back clean. The exposure is unchanged.

Where This Meets the Book

In Cyber Risk Is Business Risk, I argue that compliance and security are not the same discipline and should never be confused for one another. This is that argument in its purest form. There is no control failure here. There is no missed patch. Every scan passes. And a self-propagating botnet is still living inside AI infrastructure that holds your models, your source code, and your production credentials.

It also lands squarely on the first of the Three Questions I ask every board: do we actually know what is running in our environment? Not what procurement approved — what is running. Ray arrives with the data science team, not with IT. It gets deployed on the assumption of a trusted network, by people whose job is model throughput, not network segmentation. Nobody in that chain is behaving unreasonably. But nobody owns the assumption either, and an unowned assumption is exactly the kind of risk that only becomes visible in an incident report.

The board-level lesson generalizes well beyond one AI framework: a vendor's decision not to call something a vulnerability does not transfer the risk to the vendor. It leaves the risk with you, minus the paperwork that would have made you aware of it.

What to Ask Your CISO This Week

Four questions. None require a technical background.

Are we running Ray anywhere, and if so, is it on version 2.52.0 or later? CISA gave federal agencies until Friday. Your deadline is whatever you decide it is.

Is any of our AI or ML infrastructure reachable from the public internet — and who checked most recently? Two hundred thousand exposed servers is not a story about careless amateurs. It is a story about a default that quietly stopped matching reality.

How do we track vulnerabilities that vendors have disputed or declined to patch? If the answer is "our scanner handles it," the honest answer is that we don't. Ask specifically how many disputed CVEs are in our environment right now.

Where else in our stack are we relying on a vendor's assumption that we deploy the product correctly? Ray is not unique. It is just the one with a CISA deadline this week.

The pattern here is older than AI: a product ships secure-by-assumption, the assumption quietly breaks at scale, and the gap sits in the space between the vendor's responsibility and the customer's. AI infrastructure has simply made that gap much more valuable to attack. The clusters now hold the models, the training data, and the GPUs — the three things your competitors and your adversaries most want.

Three days is a tight deadline. The disputed flaw next to it has been open for nearly three years.