WASHINGTON, 19 AUG 2026 — A flaw in Ray, the framework most large machine-learning clusters are built on, is being actively exploited and now carries a three-day federal remediation deadline. It is reachable through a victim's web browser, and one campaign has been turning GPU clusters into a self-replicating cryptocurrency mining botnet.
The underlying design was not a mistake, which is the uncomfortable part. Ray's documentation has for years stated that its critical endpoints carry no authentication.
The vulnerability
The weaknesses are classified as CWE-94, improper control of code generation, and CWE-352, cross-site request forgery. The vulnerable endpoints are /api/jobs and /api/job_agent/jobs/, which accept job submissions and therefore execute code by design.
The chain combines a DNS rebinding attack, which lets a hostile web page reach a service bound to the developer's own machine, with manipulation of the User-Agent header to get past the checks that were there. The fetch bypass was found by Avi Lumelsky of Oligo and the rebinding technique by Jonathan Leitschuh; the advisory is tracked as GHSA-q279-jhrf-cc6v.
Why a browser is the delivery mechanism
Most people picture cluster compromise as something that happens at the network edge. This does not.
A developer with a Ray instance running locally, or reachable inside the corporate network, visits a web page. That page resolves a hostname it controls, then re-resolves it to a local address, so the browser believes it is still talking to the original site and sends requests to the Ray instance instead. Ray, which expects no authentication on those endpoints, accepts the job and runs the code.
Because the request originates inside the network from a user's browser, it never crosses a firewall in the direction that is monitored. Perimeter controls and network segmentation do very little against an attack that starts on the inside.
The design decision underneath it
Ray's maintainers have long held that authentication is not the framework's job. They reasoned that a cluster runs inside a trusted network, and the operator is responsible for securing the boundary — a defensible architecture for a data-centre batch scheduler, but a poor one for software that also runs on laptops.
The framework's threat model assumed a trusted-network environment that vanished the moment machine-learning work moved onto developer machines, CI runners and container images. Browser-based attacks defeat network trust by construction, because the browser is already inside.
This is the second time this month we have written about a defect that is really an assumption rather than a bug. The Unisoc modem chain crossed from radio firmware into the Android kernel because the isolation everyone assumed existed did not.
What has already been done with it
Two campaigns are on the record and they are unusually instructive together.
The operators of the RondoDox distributed denial-of-service botnet added the vulnerability to their tooling two days before it was publicly disclosed on 26 November 2025. That inverts the usual assumption that public disclosure starts the clock.
The second campaign, dubbed ShadowRay 2.0, turns unpatched Ray instances on Nvidia GPUs into a self-replicating cryptocurrency mining botnet. Ray clusters are a rational target. They are, by definition, large pools of accelerators with a job scheduler, which is most of what a mining operation needs.
What this means for AI infrastructure in this region
Ray sits underneath a great deal of the AI work being stood up across Southeast Asia, usually without anybody choosing it deliberately.
Ray often arrives as a dependency in distributed training tutorials, managed notebook platforms, and the reference architectures vendors hand to new teams. An organisation building its first serious model pipeline is therefore likely to be running it, but unlikely to know which version. That combination — high adoption, low visibility — is the profile that makes a three-day deadline unrealistic in practice.
The risk is particularly acute for organisations building regional AI capacity on rented GPUs. A mining campaign that quietly consumes accelerator time looks like poor utilisation, not a compromise, until the bill for wasted capacity arrives. The bill arrives as wasted capacity, not as an alert.
Three days is now the shape of these deadlines
CISA gave federal agencies until 20 August, which is three days. We noted the same window on a Cisco firewall flaw and reported CrowdStrike's finding that 88 per cent of exploitation against flaws with public proof-of-concept code now lands inside 48 hours.
Discovery makes this patch harder than one for a firewall. Ray is a Python dependency that can turn up in uncatalogued places like a data scientist's workstation, a CI runner, a container base image, a Kubernetes workload or a managed notebook service. The first task is not patching; it is finding the software.
What to do, in order
Search your dependency manifests and container images for Ray before anything else, then upgrade every instance to 2.52.0 or later. Treat developer laptops as in scope, because the browser-based path means they are the likely entry point rather than an afterthought.
Then check whether any Ray dashboard or API is reachable from outside the machine at all, and bind it to localhost or put it behind an authenticating proxy if it is. And look for the obvious sign of the mining campaign: sustained GPU utilisation that does not correspond to a scheduled job.
The broader lesson is the one we keep arriving at. Model endpoints, agent credentials and machine-learning infrastructure are rarely on the asset register that every other control is built from, and a framework nobody listed cannot be patched on a three-day deadline.
What we could not establish
How many instances are exposed and where. No survey of internet-reachable or browser-reachable Ray deployments accompanies the KEV addition, so the size of the exposed population is unknown.
It also remains unestablished how many organisations the ShadowRay campaign has affected or how much compute it has consumed. We do not know if the RondoDox operators found the flaw independently, if exploitation has occurred against full clusters, or if Ray's maintainers will change their authentication policy.
We also could not verify the technical chain first-hand. This account rests on the advisory, the KEV entry and reporting of both.
What to watch
The main thing to watch is whether Ray adds authentication by default. Patching one bypass leaves the underlying design assumption intact, and that assumption is the root of the problem.
Then watch whether managed platforms that embed Ray publish their own advisories. A great many organisations consume it inside a vendor's product and will never see a Ray version number, which makes the vendor's disclosure the only route by which they learn they were affected.
Finally, watch for the same technique against other machine-learning tooling. Notebook servers, experiment trackers and model registries share the same heritage — built for a trusted network, now running on laptops — and DNS rebinding works against all of them equally well.
View author profile → · Editorial policy
