CISA added CVE-2025-62593, a code-injection flaw in the Ray AI framework, to its Known Exploited Vulnerabilities catalog on August 17, 2026. The Ray project says releases before 2.52.0 are affected and version 2.52.0 fixes the issue. Its advisory describes a browser-based DNS-rebinding route that can lead to arbitrary code execution against a developer's local Ray service.
This is a current exploitation signal for an older disclosure, not evidence that every Ray deployment is exposed. The vendor advisory was published on November 26, 2025 and specifically describes a path involving Firefox or Safari, a malicious website, and a locally running Ray development service. Teams need to test whether those conditions exist in their own environments before describing impact.
What CISA says about the Ray AI framework vulnerability
CISA's catalog names CVE-2025-62593 as the Ray Code Injection Vulnerability. The August 17 entry says the issue can allow remote code execution and records August 20, 2026 as the remediation due date for the federal agencies covered by the applicable CISA directive. The catalog lists known ransomware use as unknown. Unknown is not the same as absent: it means the catalog does not attribute known ransomware use in that field.
Inclusion in the catalog means CISA has evidence of exploitation in the wild. The public entry does not identify victims, exploitation volume, attacker identity, or a campaign. Those details should not be inferred from the catalog status. For organizations outside the directive's federal scope, the due date is a useful urgency signal rather than a general legal deadline.
How the browser-to-local-service path works
The Ray security advisory explains the technical scope. According to the Ray project, an attacker can use DNS rebinding from a malicious website to make browser requests reach a Ray service running on the developer's machine. The advisory identifies Firefox and Safari as browsers in the demonstrated exposure path. If successful, the flaw can let the attacker submit work to Ray and execute code with the permissions available to that service.
This matters because a service that appears local can still be reachable through a browser-mediated request. Treating the loopback boundary as sufficient authentication leaves a gap when browser and DNS behavior allow an untrusted origin to address the service. The NVD record provides the public CVE record and points defenders back to the vendor advisory and related references.
The conditions are important. The advisory does not establish that every production cluster, managed Ray service, or browser is vulnerable in the same way. Exposure depends on the Ray version, whether the relevant service is running and reachable, browser behavior, network configuration, and the privileges of the Ray process. The advisory says Chrome is not affected by the demonstrated path. Teams should still test their exact browser versions and configurations.
Why this is an AI infrastructure governance issue
Ray is used to distribute Python and AI workloads. A compromised local Ray service can therefore sit close to source code, model artifacts, datasets, cloud credentials, notebooks, and developer access. The immediate problem is code execution, but the governance consequence is loss of confidence in who initiated a workload, what data it touched, and whether resulting artifacts are trustworthy.
An accurate response starts with inventory. Security teams need to know where Ray is installed, which versions are present, who launches local services, which browser paths are allowed, and what credentials or storage those processes can reach. Maetra's guide to building an AI agent inventory offers a useful model for recording owners, environments, permissions, and dependencies rather than maintaining only a package list.
Operational response for security and platform teams
Use the following checks for developer workstations, notebooks, build environments, research systems, and shared AI platforms:
- Find Ray installations and running services, then record the version, host, owner, launch method, and environment purpose.
- Upgrade affected installations to Ray 2.52.0 or later, following the vendor advisory and normal change controls.
- Where an upgrade cannot be completed immediately, stop the service or apply the vendor's recommended mitigation and document the exception owner and expiry.
- Review whether local Ray services rely on network location as their only trust boundary. Add authentication, binding, firewall, and browser-origin controls appropriate to the environment.
- Rotate credentials and inspect relevant logs when an exposed service ran with access to source repositories, cloud tokens, datasets, or model artifacts.
- Test the browser and DNS path in an isolated environment. Do not assume a configuration is protected solely because the service is addressed through localhost.
- Capture evidence of the patched version, service restart, exposure test, and review decision for each in-scope system.
- Monitor Ray tasks, process creation, tool use, and outbound connections for behavior inconsistent with the system's approved purpose.
The last step matters after patching. Maetra's guide on monitoring AI agents for risky behavior shows how to connect consequential actions to an owner, policy decision, and reviewable record.
Maetra analysis: local AI services need explicit trust boundaries
The broader lesson is that local AI infrastructure is not automatically low risk. Developer services often combine powerful execution with convenient defaults and broad access to the user's environment. A browser can become an unexpected bridge between an untrusted site and that local capability.
Teams should define the trust boundary for each AI service in terms of identity, origin, network route, process privilege, data access, and observable actions. Patch status is one control in that model. It does not replace credential review, least privilege, logging, or evidence that the exposed path is closed.
A practical next step is to add Ray services to the AI system inventory, link each entry to its vulnerability and patch record, and require an owner to attest to the current version and reachable interfaces. Teams can then use Maetra's Secure workflow to examine tool and action boundaries while keeping infrastructure remediation under their established security process.
Sources
- CISA: Known Exploited Vulnerabilities Catalog JSON, CVE-2025-62593 added August 17, 2026.
- Ray project: GHSA-q279-jhrf-cc6v security advisory, published November 26, 2025.
- NIST National Vulnerability Database: CVE-2025-62593, public vulnerability record.