CISA’s latest addition to the Known Exploited Vulnerabilities catalog concerns CVE-2025-62593, a critical remote code execution vulnerability in Ray, the distributed computing framework widely used for AI, machine-learning and Python workloads. The vulnerability affects Ray versions before 2.52.0 and carries a CVSS v4 score of 9.4. What makes this vulnerability particularly interesting is that an attacker does not necessarily need direct network access to the Ray cluster. Instead, the attack can abuse the developer’s web browser as an intermediary, allowing a malicious website or advertisement to reach a Ray instance that may be running locally or inside a private network.

The core security problem is that important Ray API endpoints, including job-submission functionality, historically did not implement conventional authentication. Ray attempted to protect these interfaces from browser-based attacks by checking whether the HTTP User-Agent began with “Mozilla” and rejecting requests that appeared to originate from a browser. Unfortunately, this protection depended on an assumption that the browser could not meaningfully manipulate the User-Agent value. The Fetch specification allows that header to be modified in circumstances relevant to Firefox and Safari, making the protection insufficient. When combined with DNS rebinding, an attacker-controlled web page can potentially send requests to the victim’s Ray API and submit arbitrary workloads.

DNS rebinding is what makes the vulnerability particularly clever. Normally, the browser’s same-origin security policy prevents a malicious website from directly communicating with services on `localhost` or private network addresses. In a DNS rebinding attack, an attacker controls a domain and initially resolves it to an attacker-controlled server. After the browser has loaded the malicious content, DNS responses are changed so that the same domain resolves to a private or loopback address. The browser may then treat requests as belonging to the same origin even though they are now being delivered to a service running somewhere completely different. The victim’s browser effectively becomes a proxy that crosses the network boundary on behalf of the attacker.

An attack therefore does not necessarily require the Ray dashboard to be exposed to the Internet. A developer could be running Ray only on the local workstation or accessing an internal Ray cluster that external attackers cannot reach. If that developer visits a malicious website in an affected browser, the browser can potentially communicate with the otherwise inaccessible Ray environment. This is an important architectural lesson because traditional perimeter controls may correctly prevent Internet systems from directly reaching the Ray cluster while still permitting a developer’s browser to communicate with both the Internet and the internal environment.

Once the attacker reaches Ray’s unauthenticated job API, the problem becomes significantly more serious. Ray is designed to execute distributed Python workloads, so the ability to submit an unauthorized job can translate directly into arbitrary code execution. Successful exploitation could therefore give an attacker the ability to execute commands under the privileges of the Ray process, access local files and credentials, install additional malware, establish persistence or use the compromised system as a stepping stone toward other resources accessible from the Ray environment. The vulnerability is classified under both CWE-94, improper control of code generation, and CWE-352, cross-site request forgery.

The consequences become considerably greater when Ray is running in an AI or machine-learning environment. Ray clusters frequently have access to GPUs, cloud credentials, object-storage buckets, training datasets, model files, source code and internal APIs. A successful compromise may therefore expose considerably more than the individual host running the vulnerable service. An attacker compromising a Ray head node could potentially obtain information about worker nodes, credentials available to the workload and access paths into the surrounding cloud or development environment.

This is one reason AI infrastructure is becoming increasingly attractive to attackers. GPU resources themselves have financial value for cryptocurrency mining or other computation, while proprietary datasets and trained models may represent extremely valuable intellectual property. AI development environments also tend to be highly interconnected because researchers need convenient access to datasets, notebooks, source-code repositories and compute clusters. Convenience, as technology repeatedly demonstrates with almost comic consistency, tends to become part of the threat model eventually.

The exploitation history makes CVE-2025-62593 even more noteworthy. Bitsight observed the RondoDox botnet attempting to exploit the vulnerability on November 24, 2025, two days before the CVE was formally published on November 26. Bitsight’s research found that RondoDox had incorporated an extraordinary 174 different vulnerabilities into its exploitation framework and was actively following newly published vulnerability research rather than merely waiting for CVE assignments.

There is an interesting complication in those observations. Bitsight noted that the RondoDox implementation appeared to contain an error: the botnet explicitly sent a User-Agent beginning with “Mozilla,” which should trigger Ray’s browser-protection check and therefore make that particular implementation ineffective. This does not mean the vulnerability is not being successfully exploited elsewhere. It simply demonstrates that identifying exploitation attempts and confirming successful exploitation are different things. CISA’s decision to place CVE-2025-62593 in KEV indicates that sufficient evidence now exists for the agency to consider the vulnerability actively exploited.

The vulnerability was fixed in Ray 2.52.0, and organisations running earlier versions should therefore upgrade to 2.52.0 or later as the primary remediation. This should be treated as a priority for developer workstations and clusters accessible from browsers used for ordinary Internet activity. Simply confirming that the Ray cluster is not publicly exposed is not sufficient because the entire significance of this attack is that the browser can potentially bridge the external website and the internal Ray service.

Organisations should also review how Ray interfaces are exposed. Ray dashboards and job APIs should not be reachable from general employee or workstation networks unless there is an operational requirement. Access should ideally be restricted to dedicated management networks, authenticated gateways or tightly controlled administrative hosts. Network segmentation remains useful even against browser-assisted attacks because it limits which internal destinations a compromised developer workstation can reach.

Developer workstations deserve particular attention. A user working with AI infrastructure should not automatically have unrestricted browser access to every internal management interface simply because the systems share the same corporate network. Network policies can separate ordinary web-browsing activity from administrative access to compute infrastructure, while browser isolation or dedicated administrative workstations can provide further protection in sensitive environments.

Ray clusters should also operate under least-privileged service identities. If a Ray process is compromised, the amount of damage should be limited by what that process is authorized to access. Ray workers generally should not receive broad cloud-administrator privileges or unrestricted access to storage simply because doing so makes development easier. Workload identities should be scoped to the minimum datasets, buckets and APIs required for the specific task.

Cloud credentials deserve special scrutiny. Environment variables, instance metadata, configuration files and mounted secrets can all become accessible after arbitrary code execution. Organisations should therefore review what credentials are exposed to Ray workloads and whether those credentials can be rotated quickly after suspected compromise. Short-lived workload identities are preferable to long-lived API keys because stealing a permanent cloud credential can turn one compromised AI workload into a much larger cloud incident.

Monitoring should focus on Ray job-submission activity as well as ordinary endpoint telemetry. Unexpected requests to `/api/jobs`, unfamiliar job definitions, commands executed outside normal development workflows, unusual child processes spawned by Ray components and unexpected outbound connections from cluster nodes should be investigated. Security teams should also establish what normal Ray activity looks like so they can distinguish legitimate distributed workloads from attackers using legitimate job-execution functionality.

Outbound network controls can further reduce the impact of exploitation. Ray workers normally require access to a relatively predictable set of services, such as storage, code repositories and internal APIs. They should not automatically be able to communicate with arbitrary destinations on the Internet. Restricting outbound connectivity can make command-and-control, malware downloads and data exfiltration more difficult even after an attacker achieves code execution.

Organisations that ran vulnerable Ray versions should also consider retrospective investigation rather than treating installation of version 2.52.0 as the entire response. Because exploitation activity dates back to at least November 2025, security teams should review historical telemetry for unexplained Ray job submissions, suspicious shell commands, cryptocurrency miners, unfamiliar processes, unexpected account creation and unusual network connections. Patching closes the vulnerability going forward; it provides no assurance that somebody did not already walk through the door while it was open.

The incident also reveals a broader weakness in the way many AI frameworks have evolved. Tools originally designed for researchers and trusted development environments are increasingly being deployed as production infrastructure without traditional security controls such as strong authentication, authorization and hardened management interfaces. Ray’s lack of authentication on sensitive job endpoints was a deliberate design assumption rather than an accidental missing password field. Once the environment in which the software operates changes, however, those assumptions can become vulnerabilities.

Security teams should therefore inventory AI development infrastructure with the same seriousness applied to databases, hypervisors and production servers. Notebook servers, model registries, experiment trackers, inference endpoints and distributed-computing frameworks can all execute code and often possess extensive access to valuable data. They should be included in vulnerability management, network segmentation, identity governance and threat monitoring rather than existing in a separate technological universe labelled “data science.”

CVE-2025-62593 is particularly valuable as a defensive lesson because the attacker does not defeat the firewall directly. The firewall may correctly block inbound access to the Ray cluster. The browser already has permission to communicate outward to the Internet and inward toward development services, so the attacker manipulates that trusted client into becoming the pathway. Security architecture therefore has to consider not only whether an external attacker can directly reach an internal service, but whether another trusted component can be persuaded to reach it on the attacker’s behalf.

CISA’s inclusion of CVE-2025-62593 in the KEV catalog should therefore move the vulnerability from ordinary patch queues into active remediation. Organisations should upgrade Ray to 2.52.0 or later, restrict access to Ray management APIs, isolate AI infrastructure, minimise workload privileges, review cloud credentials and investigate vulnerable systems for evidence of prior exploitation. The larger message is equally important: as AI platforms gain access to increasingly valuable compute, models and data, the infrastructure surrounding AI is becoming as attractive to attackers as the applications it supports. Protecting the model while leaving the framework capable of unauthenticated code execution would be a rather unfortunate interpretation of AI security.

CISA has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-64849 MLflow Server-Side Request Forgery Vulnerability This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. 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 high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nomination Form . Pot

Source: CISA Adds One Known Exploited Vulnerability to Catalog via CISA Advisories — published 19 Aug 2026.