Is CVE-2025-62593 (Ray-Project Ray Code Injection) being exploited in the wild?

Yes. CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalogue on 17 August 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ray-Project Ray contains a code injection vulnerability that could allow remote code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

CISA listing a CVE in KEV is the practical signal that matters here. For operators, it means the issue is no longer theoretical, so exposure should be assumed until you have confirmed otherwise. In this case, the risk is not just a vulnerable version, but active abuse of a code injection path that can lead to remote code execution.

For Ray users, the first question is whether any production or internet-reachable Ray deployment is within the affected footprint. If the answer is yes, the issue moves from vulnerability management into incident-ready response, because exploitation can change the system state, not just create a patching backlog.

That is why exploitability and exploit status matter more than the CVE title alone. A code injection flaw in a distributed compute platform can expose workloads, commands, secrets in memory, and adjacent infrastructure, depending on how the cluster is deployed and what the runtime can reach.

What to check before you assume you are safe

Start with asset confirmation: find every Ray deployment, including staging, shared lab environments, and ephemeral clusters, then determine which instances are externally reachable or exposed through internal trust paths. A deployment is not safe just because it sits behind a cloud perimeter if jobs, dashboards, or control interfaces remain reachable from other compromised systems.

Next, validate whether the vulnerable component is actually in use and whether compensating controls truly reduce exposure. For exploited vulnerabilities, “we planned to patch later” is not a control. You need an inventory that answers where Ray runs, who can access it, and what downstream systems a successful injection could touch.

For this kind of issue, CISA Known Exploited Vulnerabilities Catalog and NIST National Vulnerability Database should be used together, one for exploitation status and one for record-level vulnerability context. If you need a structured triage path for the broader response, use Zero-Day and Exploited Vulnerabilities Guide as the operational playbook.

How urgent remediation changes when exploitation is confirmed

When a flaw is actively exploited, the remediation priority is immediate containment, then repair, then validation. If patching is available, it should be scheduled as an emergency action, not folded into the next routine cycle. If patching is not yet possible, isolate the service, reduce exposure, and remove unnecessary network reachability or administrative access paths.

Because code injection can create remote execution, the remediation decision should also include blast-radius thinking. If Ray has access to data stores, artifact repositories, cloud credentials, or orchestration tooling, assume those paths may need review even if the vulnerable service itself is later patched.

The right operational model is closer to active-exploitation handling than ordinary vulnerability management. Vulnerability Management Guide is most useful here when you need prioritisation discipline, exception handling, and post-remediation verification, while FIRST EPSS helps with prioritisation context rather than deciding whether to act.

Risk and Threat Considerations

Active exploitation changes the threat model from “vulnerable software may be abused” to “someone may already have used the flaw to execute code.” With a code injection issue in an orchestration or compute platform, the most important concern is not the CVE label but the possibility of unauthorized commands, credential exposure, lateral movement, or persistence inside the cluster.

Failure mechanism: An attacker abuses the injection path to execute attacker-controlled input as code or commands, then uses the resulting execution context to reach data, secrets, or adjacent management surfaces before defenders patch the flaw.

Impact: The compromise can extend beyond the Ray node itself to workloads, secrets, cloud resources, or internal services reachable from the cluster, which is why post-compromise checks matter even after remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified And Recorded	Ray exposure assessment depends on identifying where the vulnerable service exists.
	DE.CM-01 — Networks And Network Services Are Monitored To Find Potential Cybersecurity Events	Active exploitation requires monitoring for signs of malicious activity and reachability changes.
Recommendation — Inventory every Ray deployment and record exposed instances for urgent response. Monitor Ray control planes and edges for exploitation indicators and unusual access.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The CVE requires confirmation of exposure and rapid prioritization based on known exploitation.
	SI-2 — Flaw Remediation	Known exploitation makes emergency patching and mitigation the primary control response.
	IR-4 — Incident Handling	Confirmed exploitation requires containment and compromise assessment, not routine patching alone.
Recommendation — Scan for vulnerable Ray instances and prioritize remediation using exploit status. Apply emergency remediation or mitigation to affected Ray deployments immediately. Treat suspected Ray exploitation as an incident and investigate for persistence and spread.

Practitioner Guidance

What to prioritise: Treat confirmed exposure as an emergency if Ray is internet-facing or reachable from higher-trust networks. Prioritise isolation and patching over debate about whether exploitation is “likely,” because KEV inclusion already answers that question for operational purposes.

What to verify: Confirm whether any Ray deployment handled sensitive jobs, tokens, API keys, or privileged service credentials. If the platform could have accessed secrets or management APIs, validate whether those materials need rotation or revocation after remediation.

Decision rule: If you cannot prove the environment was unreachable and unexposed, proceed as if compromise is possible and perform targeted compromise assessment before declaring the issue closed.

Practitioner takeaway: For an exploited CVE, the real question is not whether patching is available, but whether the vulnerability has already altered trust in the environment. If it has, remediation must include exposure reduction and compromise review, not just software replacement.