As reported by CISA on August 17, 2026, the agency has added CVE-2025-62593 — a code injection vulnerability in the Ray-Project Ray distributed computing framework — to its Known Exploited Vulnerabilities (KEV) Catalog. This designation confirms that threat actors are actively exploiting this flaw in the wild, elevating it from theoretical risk to immediate operational threat.
Why Ray Makes an Attractive Target
Ray is an open-source framework widely adopted for scaling Python and AI/ML workloads across distributed clusters. It powers training pipelines, reinforcement learning, model serving, and data processing at organizations ranging from startups to large enterprises. Its core value proposition — enabling arbitrary code execution across a cluster by design — means that any injection flaw in its control plane can effectively grant attackers the ability to run code on every node in the cluster. This transforms a single vulnerability into a potential full-cluster compromise.
Ray deployments frequently run with elevated privileges to access GPU resources, training datasets, and model artifacts. A successful exploitation could expose proprietary models, sensitive training data, and cloud credentials stored in the environment. The convergence of AI infrastructure and security gaps creates a high-value target that threat actors are clearly recognizing.
Vulnerability Summary
| Field | Detail |
|---|---|
| CVE ID | CVE-2025-62593 |
| Vendor / Product | Ray-Project / Ray |
| Vulnerability Type | Code Injection |
| Severity | Refer to NVD entry for official CVSS score |
| Active Exploitation | Confirmed — added to CISA KEV Catalog |
| Patch / Mitigation | Check Ray-Project advisory and GitHub releases |
| Binding Directive | BOD 26-04 (FCEB agencies must remediate) |
Who Is Most Exposed
Broader Implications: AI Infrastructure as Attack Surface
The KEV addition underscores a growing pattern: the tooling that powers the AI boom is becoming a preferred target for adversaries. Frameworks like Ray, MLflow, and JupyterHub were designed for collaborative research environments with implicit trust assumptions. As these tools move into production enterprise environments, their security model has not kept pace with their deployment footprint.
Organizations scaling AI capabilities should treat ML orchestration infrastructure with the same security rigor applied to production databases and identity providers — not as research tooling that sits outside the hardened perimeter.
Immediate Actions
- Inventory Ray deployments: Identify all instances of Ray across development, staging, and production environments. Check for exposed dashboards or job submission APIs using external scanning.
- Apply patches: Update to the latest patched Ray release as specified in the project's security advisory. If no patch is available yet, implement compensating controls immediately.
- Restrict network exposure: Ensure the Ray dashboard and client APIs are not accessible from the internet. Place them behind VPN, bastion hosts, or private subnets. Disable the dashboard if not required for operations.
- Enable authentication: If running a version that supports Ray dashboard authentication, ensure it is enabled and not left at default no-auth configuration.
- Hunt for compromise: Review Ray job submission logs, cluster event logs, and node system logs for unexpected job submissions, unfamiliar Python packages, or outbound network connections from Ray worker nodes. Check for new processes spawned by Ray services.
- Rotate credentials: If any Ray cluster was exposed and compromise cannot be ruled out, rotate all cloud credentials, API keys, and secrets accessible from the cluster environment.
Shield53 Recommendations
- Treat all ML orchestration platforms as Tier-1 production infrastructure — enforce network segmentation, authentication, and logging regardless of whether the team considers it "research tooling."
- Implement continuous asset discovery for AI/ML frameworks. Shadow Ray deployments spun up by data science teams are a common blind spot.
- Subscribe to CISA's KEV Catalog feed and automate alerting when entries match your asset inventory. The gap between KEV addition and remediation is a measurable risk metric your board should see.
- For FCEB agencies: document remediation timelines and post-compromise check results per BOD 26-04 requirements. Non-federal organizations should voluntarily adopt the same standard.
- Conduct a focused review of all Ray cluster configurations for default credentials, open dashboards, and overly permissive IAM roles attached to worker nodes.
