CISA Adds a Ray Flaw to Its Known Exploited List - The Target Is the Developer's Own Machine

On August 17, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added one vulnerability to its Known Exploited Vulnerabilities (KEV) catalog ¹. The entry is CVE-2025-62593, “Ray-Project Ray Code Injection Vulnerability” — a code injection flaw in the distributed computing framework Ray ¹.

The KEV catalog lists vulnerabilities confirmed to be exploited in the wild, and CISA states that this addition is based on evidence of active exploitation ¹. The vulnerability itself is not new. The GitHub Security Advisory from the project was published on November 26, 2025, and Ray 2.52.0 already contains the fix ³. What changed is the judgment that it is actually being used.

The Target Is “Developers Using Ray as a Development Tool”

The KEV catalog entry describes it this way: Ray contains a code injection vulnerability that could allow remote code execution, and developers using Ray as a development tool may be exposed to this vulnerability, exploitable through Firefox and Safari ².

What stands out is that this is not a server-side story. The project’s advisory is titled “Critical RCE Vulnerability against Ray Devs exploitable via Browser (Safari & Firefox) due to DNS Rebinding Attack” ³.

The mechanism combines a thin defense with a classic browser weakness. According to the advisory, the Ray development team’s longstanding decision not to implement any authentication on critical endpoints such as /api/jobs and /api/job_agent/jobs/ has once again led to a severe vulnerability allowing arbitrary code execution against Ray ³. A defense against browser-based attacks did exist, but it only checked whether the User-Agent header starts with the string “Mozilla” — and the fetch specification allows the User-Agent header to be modified, so the defense is insufficient ³.

Combine that with a DNS rebinding attack against the browser, and the flaw becomes exploitable against a developer running Ray who inadvertently visits a malicious website, or is served a malicious advertisement (malvertising) ³. The advisory’s impact section is blunt: if they fall victim to a phishing attack or are served a malicious ad, arbitrary shell code can be executed on their developer machine ³.

There is a second path that widens the blast radius. The attack can also be leveraged to attack network-adjacent Ray instances running inside a private corporate network, using the browser as a confused deputy intermediary ³. The browser on a developer’s desk becomes the entrance to a Ray instance that was supposed to be on the inside.

The CVSS v4 score is 9.4, rated Critical ³. Affected versions are the Python package ray below 2.52.0, and the patched version is 2.52.0 ³.

The Due Date Is August 20 — But Only for Federal Agencies

The remediation deadline appears on the KEV catalog entry rather than in the alert. The CVE-2025-62593 entry has a date added of August 17, 2026 and a dueDate of August 20, 2026 ².

The scope of obligation is limited too. The alert explains that Binding Operational Directive (BOD) 26-04, “Prioritizing Security Updates Based on Risk,” establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies ¹. BOD 26-04 reinforces the importance of the KEV catalog and requires federal agencies to prioritize rapid remediation of KEV-listed CVEs on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities ¹.

And it says so explicitly: BOD 26-04 applies only to FCEB agencies, while CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV catalog vulnerabilities ¹. No legal deadline lands on a private company outside that scope.

The KEV entry’s required action says to apply mitigations in accordance with vendor instructions while ensuring compliance with BOD 26-04 guidance and CISA’s “Forensics Triage Requirements,” to follow applicable guidance for cloud services or discontinue use of the product if mitigations are unavailable, and that stakeholders are responsible for evaluating each asset’s internet exposure ². Known ransomware campaign use is listed as “Unknown” ².

What to Check on Your Own Machines

Ray is used to run distributed training and inference jobs, and it frequently runs locally on a developer’s laptop, not only on production clusters. Since this flaw targets exactly that, the place to check is clear: whether the Ray version on your machines and in CI is 2.52.0 or higher.

The fix is to update to Ray 2.52.0 or higher, and the advisory notes that this version also, finally, adds a disabled-by-default authentication feature that can further harden against the vulnerability ³. Whether to enable it is a separate decision, but the premise that critical endpoints have no authentication can now be changed.

Waiting on browsers looks premature. The advisory notes that several browsers, after knowing about the attack for 19 years, have recently begun hardening against DNS rebinding (Chrome Local Network Access), but that these changes may protect you while a previous initiative, “private network access,” was rolled back ³. It concludes that updating is highly recommended as a defense-in-depth strategy ³.

Credit goes to Oligo’s @avilum, who originally theorized the fetch bypass, and to @JLLeitschuh, who did the DNS rebinding step, full PoC, and disclosure while at Socket ³.

When the Machinery That Runs AI Becomes the Attack Surface

This is easier to read alongside a thread that has been running all summer than as a standalone CVE.

What Wiz showed with Snowflake’s GitHub Actions was a CI workflow anyone could trigger passing untrusted input into a shell. Here, a local development environment exposes an unauthenticated API that an external web page can reach. The common thread is that the convenience of running models and jobs is itself the attack surface.

The next day, on August 18, OpenAI disclosed that it added workload isolation and network isolation as requirements for its research environments. The design intent stated there — that a single compromise of a workload or supporting service should not, by itself, allow unauthorized access to the internet or other internal networks — is precisely the thinking that closes the “reach an internal Ray through a browser” path. The scale is entirely different, but the nature of what needs checking looks the same.

For organizations running AI workloads internally, the ground covered when Microsoft added a DevSecOps pillar to its Zero Trust Workshop overlaps directly with the scope of this check. Development machines, CI, and experiment clusters tend to be managed more loosely than production while sitting closer to models and data. A KEV addition reads as notice that the distance is actually being used.