CISA Gave 3 Days to Patch Ray. Auth Is Still Off by Default.

Upgrading Ray to 2.52.0 will close your ticket and will not lock your cluster. CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog on August 17 with a remediation deadline of August 20 — three days, not the usual two weeks. The patch it points to blocks a browser attack. It does not turn on authentication, because Ray still ships with authentication disabled by default, and the CVE filed against that fact was withdrawn from the national vulnerability database in December.

So the version bump satisfies the directive, the scanner goes green, and any host that can reach port 8265 can still submit a job and run code as you. That is not a patching problem. It is a scope problem, and it is on your side of the line.

---

What CISA Actually Ordered, and Why the Window Was Three Days

The three-day clock is not an emergency improvisation — it is the top tier of a new directive that most vulnerability programs have not finished absorbing. The KEV entry for CVE-2025-62593 lists dateAdded 2026-08-17 and dueDate 2026-08-20, and its required action cites BOD 26-04, "Prioritizing Security Updates Based on Risk", not the BOD 22-01 that federal agencies patched under for four years.

BOD 26-04 replaced the flat two-week KEV deadline with a four-variable model — is the asset publicly exposed, is the CVE in KEV, is exploitation automatable, and does exploitation yield total control. Tenable's breakdown of the directive maps those variables to five tiers: 3 days with mandatory forensic triage for KEV plus total control, 3 days without triage when an exposed asset is automatable and yields total control, 14 days as the standard accelerated path, 60 days for lower-risk combinations, and deferral to the next system upgrade for everything that trips none of the four.

Ray landed in the top tier. Unauthenticated remote code execution on an internet-reachable box is total control and is trivially automatable. The practical consequence for a federal agency is not just "patch by Thursday" — it is "patch by Thursday and determine whether you were already compromised." Forensic triage is a separate workstream from remediation, and it is the half that gets dropped when a team treats a KEV item as a version number.

You are probably not an FCEB agency. It does not matter much. KEV listings propagate through FedRAMP continuous monitoring, cyber-insurance questionnaires and vendor patch SLAs, and "was it on KEV, and when did you remediate" is the first question in a post-incident coverage dispute. A three-day federal deadline becomes a contractual one in a lot of enterprise paper.

---

What the 2.52.0 Patch Fixes — and What It Leaves Wide Open

The fix stops a browser from attacking your Ray dashboard. It does nothing about the network. Read the commit CISA links in its own KEV notes and the scope is unambiguous: it adds a has_sec_fetch_headers() check for Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-Site and Sec-Fetch-User, and returns 405 Method Not Allowed when a request carrying any of them arrives as a POST or PUT. GET stays open — the tests say so explicitly.

That is the right fix for the bug that was filed. The advisory describes a CVSS 9.4 chain in which Ray's only browser defense was checking whether User-Agent started with Mozilla; Firefox and Safari let fetch() rewrite that header, and combined with DNS rebinding a malicious ad could make a developer's own browser POST a shell command to localhost:8265. Sec-Fetch headers cannot be forged by page JavaScript, so the chain breaks.

Now write the same request with curl from a pod on the same VPC. No Sec-Fetch headers. No Mozilla user agent. The middleware sees a normal API client, and /api/jobs/ accepts it, because there is no authentication in front of it. Ray's own documentation states the model plainly: "Security and isolation must be enforced outside of the Ray Cluster," and "Ray faithfully executes code that is passed to it — Ray doesn't differentiate between a tuning experiment, a rootkit install, or an S3 bucket inspection."

This is the exact path Oligo's ShadowRay 2.0 research documented in November 2025 — read with the caveat that Oligo sells AI infrastructure security, which does not make the findings wrong but does mean the exposure number is a vendor's. That number, over 200,000 Ray servers, is a Shodan count of hosts answering on the internet, not a count of confirmed compromises; Oligo does not separate the two. What it does document concretely is an actor spraying payloads at the completely unauthenticated Jobs API, and compromised clusters turned into self-propagating XMRig miners and DDoS nodes. The malware capped itself at roughly 60% CPU, renamed its processes to look like [kworker/0:0], and hid GPU consumption from Ray's own dashboard while burning 23.9 GB of VRAM. Oligo puts the on-demand price of one hijacked cluster at over $3 million a year in compute. Attackers also walked off with MySQL credentials pulled from Ray job environment variables and config files, and with source code, models and datasets from mounted NFS shares — which is a credential-rotation exercise, not a patching one.

Exploitation is not theoretical or slow. Bitsight's RondoDox infrastructure analysis found operators had weaponized CVE-2025-62593 two days before it was publicly disclosed on November 26, 2025 — the standout case in that botnet's arsenal, which Bitsight attributes to a proof-of-concept that was public before the CVE was. The rest of the arsenal trailed disclosure by weeks or longer.

---

The CVSS 10.0 Your Scanner Will Never Show You

The vulnerability that actually leaves your cluster open has no valid CVE, which is why nothing in your toolchain reports it. When Ray 2.52.0 shipped token authentication, the researcher who reported the browser chain filed a second advisory — "Ray: New Token Authentication is Disabled By Default" — scored CVSS 10.0 under the rule that insecure default configurations should be treated as vulnerabilities. It was assigned CVE-2025-34351.

Then it was withdrawn. The MITRE record shows state REJECTED as of 2025-12-02, with the reason that "this assignment did not identify a valid vulnerability based on the vendor's product security model" and "conflicts with an existing CVE (CVE-2023-48022)." NVD carries it as rejected with no score at all.

And the CVE it was folded into is itself contested. CVE-2023-48022 — CVSS 9.8, unauthenticated RCE via the job submission API — is flagged DISPUTED on NVD, carrying the vendor's position verbatim: "Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment."

Put those together and you get a specific, checkable failure mode in your own process. A dependency scanner reading OSV or NVD sees one actionable Ray finding — CVE-2025-62593, fixed in 2.52.0. It does not see a rejected CVE. Most teams suppress disputed ones. So the remediation your tooling can prove is the one that changes the least, and the control that would actually stop ShadowRay is invisible to the system of record you report from. This is the same shape as the Flowise CVSS 10 finding in AI agent tooling: the number moves procurement, and the number is an artifact of who filed what.

A rejected CVE is not a fixed vulnerability. It is an unowned one.

---

Turning Auth On at 2.52.0 Has Its Own Hole

If you do enable token authentication, do it on 2.56.0 or later — the version CISA names is not the version that holds. Ray's token authentication guide confirms the feature arrived in 2.52.0 and is "disabled by default," with the project planning to enable it "in a future release." As of the current docs, that future has not arrived. Anyscale's own announcement frames it as shipping "as an opt-out to ease migration," with the default flipping in future releases.

Meanwhile the same browser-blocking middleware that 2.52.0 hardened had a second gap. GHSA-q5fh-2hc8-f6rq / CVE-2026-27482 — moderate, 5.9 — covers DELETE endpoints the POST/PUT check never touched, letting an unauthenticated request shut down Serve deployments or delete jobs. Affected: Ray < 2.54.0. And 2.54.0 is not the end of it — CVE-2026-41486, high, 8.9, is remote code execution that needs only a crafted Parquet file in a path a Ray Data pipeline reads, because the Arrow extension metadata goes straight to cloudpickle. It affects 2.49.0 through 2.54.0 and is fixed in 2.55.0. Nor does 2.55.0 hold: CVE-2026-57516, high, 8.8, disclosed in July, is arbitrary code execution through ray.data.read_webdataset(), whose default decoder hands .pkl files to pickle.loads and .pt files to torch.load with weights_only=False during schema sampling — before any of your code touches the data. A poisoned TAR from S3 or the HuggingFace Hub is enough, and it affects everything below 2.56.0, which is the current release. So the version in the KEV advisory sits below the floor for all three follow-on fixes, and a team that patches to exactly 2.52.0 and stops has bought the minimum.

The version you can actually run may not be your call. If you are on Ray through a managed surface — a hyperscaler's managed Ray, a vendor-pinned image, a platform team's golden AMI — you inherit whatever version they ship, and the KEV deadline does not move their release train. That gap is the same one that shows up whenever the control plane above an open-source project belongs to somebody else. On Kubernetes, KubeRay's auth guide requires Ray 2.52.0+ and KubeRay v1.6.0+ for the authOptions field; below that you are hand-rolling a Secret and environment variables.

One caveat worth stating before someone treats a token as a perimeter: Ray tokens are bearer secrets sent as plaintext HTTP headers, they never expire, and they sit in ~/.ray/auth_token on disk. Ray's own docs recommend TLS, SSH tunneling or a VPN alongside them. This is a defense-in-depth measure, not an identity system.

---

Ray's Position Is Defensible. Your Deployment Is Not.

The strongest version of Anyscale's argument is that Ray is a distributed execution engine, and an execution engine that runs arbitrary user code cannot meaningfully authenticate its way to safety. Every job is remote code execution — that is the product. Kubernetes' API server, Spark's master, and Dask's scheduler all carry the same property. Treating "Ray runs code you send it" as a vulnerability is close to treating bash as one, and Ray documents the boundary clearly: it does not enforce isolation between jobs, and the operator supplies the perimeter.

That argument holds in a lab. It stops holding the moment Ray becomes shared infrastructure. A cluster reachable by every CI runner, notebook and service account in a VPC is not a "strictly controlled network environment," and 200,000 instances answering on the public internet is the empirical verdict on whether the assumption survives contact with a platform team. The gap between an authorization model that is technically correct and one that survives real deployment is the same gap that keeps producing cross-agent escalations where every individual call was authorized.

Whoever is right, the operational conclusion is identical: if Ray's security is enforced outside Ray, then someone on your team owns a control Ray will never ship, and that ownership needs a name on it.

---

What to Do

This Week (before August 20):

1. Inventory, do not assume. Find every Ray head node — self-managed, KubeRay, managed service, and the notebook someone ran ray start --head on. Check the running version, not the pinned requirement.
2. Patch to 2.56.0, not 2.52.0. 2.52.0 satisfies the KEV item and leaves CVE-2026-27482 open; 2.54.0 still carries the 8.9 Parquet deserialization RCE; 2.55.0 still carries the 8.8 WebDataset decoder RCE. 2.56.0 is the current release and the first version clear of all three. If a managed provider pins you below it, open the ticket today and record the response — that record is your compensating-control evidence.
3. Scan for exposure before you scan for versions. Any dashboard or Jobs API answering on 0.0.0.0:8265 outside a private subnet is the finding. Ray's docs state it directly: "For security purposes, do not expose Ray Dashboard publicly without proper authentication in place."
4. Do the triage, not just the patch. BOD 26-04's top tier pairs remediation with forensic triage for a reason. Check for cron entries firing every 15 minutes, injected SSH keys, processes masquerading as [kworker] or dns-filter, and outbound connections to Monero pools.

This Month:

1. Set RAY_AUTH_MODE=token in the cluster template, not in a runbook. On KubeRay, use authOptions on the RayCluster CRD so it cannot be forgotten by the next person who copies a manifest. A default nobody enforces is a prompt, not a policy.
2. Rotate every credential a Ray worker can read. Environment-variable database passwords, AWS role tokens, registry credentials, model-registry keys. Assume-breach is cheap here and the ShadowRay evidence is specific about what attackers took.
3. Write the network control down and give it an owner. Ray will not provide isolation. Security group, service mesh policy or authenticating reverse proxy — pick one, name the team, put it in the runbook.

Before Your Next Audit:

1. Add "disputed and rejected CVEs" to your exception review. If your scanner suppresses them, you have a class of risk that is structurally invisible. Ray is the example this month; it will not be the last.
2. Make "remediated" mean the control works, not that the version changed. The test is a curl POST to /api/jobs/ from an unauthorized network position returning 401 — not a green row in a report.

---

The Bottom Line

Every enterprise vulnerability program is optimized to close the item it can name. CISA named CVE-2025-62593, and by Thursday a lot of organizations will have upgraded Ray, closed the ticket, and moved on with an unauthenticated distributed execution engine still sitting on their network — because the CVE that describes that condition was withdrawn, and the one it merged into is disputed.

Federal directives are getting sharper about this. BOD 26-04's highest tier already pairs patching with proving you were not compromised, which is an admission that a version number was never the whole answer. The rest of the industry has not caught up. Neither have the scanners we report from.

Ray is not unusual. It is just early — an open-source substrate that grew from research tooling into production AI infrastructure faster than its threat model did, and whose maintainers are honest that the perimeter is your job. The AI stack is full of components with exactly that history and exactly that disclaimer.

Patch by Thursday. Then go find out what the patch does not do.

Continue Reading

Ray Is Open Source. The Control Plane Above It Isn't. Claude Code Stops Asking Aug 14. Prompts Aren't Policy. One Agent Escalated Another. Every Call Was Authorized. AWS Agents Run 14 Days. The Session Is the Only Wall. 66,000 CVEs, 3-Day Patches: The White House's AI Cyber War Room AI Cyber Insurance Riders: Why 40% of Claims Get Denied