Known exploited vulnerability · August 18, 2026
CISA has given federal civilian agencies until August 20 to address CVE-2025-62593, a browser-assisted remote-code-execution flaw in the Ray distributed-computing framework. Ray versions before 2.52.0 are affected. The project fixed the issue in 2.52.0, and Ray 2.57.0 was the current release at our reporting cutoff. CISA classifies the vulnerability as actively exploited, but that phrase needs care: its KEV rules include attempted exploitation as well as successful compromise, and CISA has not published victim counts, attribution, or incident details for this entry.
The deadline in one minute
CISA KEV: added August 17 Federal due date: August 20
- CVE: CVE-2025-62593
- Product: the open-source
rayPython package and its dashboard/job interfaces - Affected: versions earlier than 2.52.0
- Minimum fixed release: 2.52.0
- Current release at cutoff: 2.57.0
- Weaknesses: code injection (CWE-94) and cross-site request forgery (CWE-352)
- Ransomware use: CISA lists it as unknown
The catalog date is three calendar dates after the addition date. It should not be described as a guaranteed, precisely measured 72-hour window because the public record gives dates rather than an addition-time-to-deadline timestamp.
What the Ray bug actually does
Ray is an open-source compute engine used to distribute Python and AI workloads across machines. Its power is also why this flaw matters: Ray is designed to execute submitted jobs. If an attacker can reach a job-submission interface, the resulting code runs with the permissions and access of the Ray service or user—not automatically as root, but potentially with access to source code, data, cloud credentials, model artifacts, and neighboring services available to that account.
According to the Ray project’s GitHub security advisory, older releases tried to block browser-originated requests by checking whether the browser’s User-Agent began with “Mozilla.” Firefox and Safari allow web code to alter that header in the relevant request path. A malicious site—or a malicious advertisement loaded by an otherwise legitimate site—can combine that bypass with DNS rebinding, using the victim’s browser as an intermediary to reach a Ray dashboard on the same computer or a private network.
The advisory specifically identifies Firefox and Safari. It says the demonstrated path did not work in Chrome because of Chrome’s handling of that header. That is not a reason to leave Ray unpatched: browser behavior changes, other access paths can exist, and Ray’s own advisory recommends the software fix rather than trusting browser quirks.
Exposure is a conjunction, not a headline. The browser-mediated path requires vulnerable Ray software, the dashboard/job service running and reachable from the browser, and a developer who loads attacker-controlled web content. A public dashboard is dangerous, but public internet exposure is not required if DNS rebinding lets the browser reach localhost or an internal address.
Why CISA says “actively exploited”
CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 17. Its machine-readable enrichment marks exploitation active, exploit automation yes, and technical impact total. That formal designation carries more weight than a public proof of concept or a high severity score alone.
CISA’s published KEV criteria also make an important distinction. For catalog purposes, active exploitation includes both:
- attempted exploitation—malicious code is aimed at a real target or honeypot but does not obtain the intended result; and
- successful exploitation—the vulnerable code is abused and the actor can take additional unauthorized actions.
CISA says the actor’s intent must be to succeed and the activity must occur in real time “in the wild.” Therefore, the KEV listing confirms real-world malicious activity that met CISA’s criteria; it does not, by itself, disclose whether every observed attempt worked or how many organizations were compromised.
The RondoDox evidence is real—but narrower than some headlines
BitSight’s March investigation of the RondoDox botnet records an attempted use of CVE-2025-62593 on November 24, 2025—two days before the public CVE record. BitSight said that timing showed operators were following vulnerability material, not merely waiting for CVE publication.
But BitSight also found the Ray attempt appeared incorrectly implemented. The request explicitly used a User-Agent beginning with “Mozilla,” which Ray’s old filter rejected. BitSight therefore assessed that observed implementation as ineffective. This is consistent with CISA’s definition, because attempted exploitation can qualify, but it is not proof that RondoDox successfully compromised a Ray system. CISA has not said RondoDox is the only activity behind the KEV decision.
Who is legally covered by the three-day date?
The compulsory deadline applies under Binding Operational Directive 26-04 to Federal Civilian Executive Branch agencies and the federal information systems within its scope, including agency systems hosted in relevant third-party and cloud environments. CISA’s current directive page says it does not apply to statutorily defined national-security systems or certain systems operated by the Department of War and the Intelligence Community. Contractors are not automatically covered unless the governing contract requires it, although agencies must review their contracts and cloud arrangements for compliance.
State, local, tribal, territorial, private-sector, and home systems are not legally bound by the federal directive. CISA nevertheless urges every organization to prioritize KEV remediation because these entries represent real adversary activity.
Why the response window is unusually short
BOD 26-04 replaced the older one-size-fits-all KEV schedule with risk-based timelines. CISA considers whether an asset is publicly exposed, whether the CVE is in KEV, whether exploitation can be automated, and whether the result gives partial or total control. For CVE-2025-62593, CISA’s public enrichment says the exploitation is active, automatable, and capable of total technical impact. The August 20 due date places this issue on a rapid track.
The related implementation guidance tells agencies to scope affected systems quickly, preserve relevant volatile and persistent evidence, patch and stabilize, contain suspected compromise, analyze for unauthorized access or persistence, and decide whether to escalate incident response. Its suggested forensic sequence extends across the first 72 hours, but CISA says those step-by-step target times are recommended practice; the binding requirement is adequate triage and remediation under the directive and KEV entry.
What Ray administrators should do now
1. Inventory the running version
Check every developer workstation, virtual environment, container image, notebook host, CI runner, cluster head node, Kubernetes deployment, and managed image that may include ray. Record the package source and running process—not just a lockfile or base image tag.
2. Upgrade beyond the vulnerable range
Move to Ray 2.52.0 or later. Where compatibility allows, prefer the current supported release rather than stopping at the first fixed build; Ray 2.57.0 was current on August 18. Test workload, API, dependency, and image compatibility before broad rollout.
3. Replace every running copy
Rebuild and redeploy containers, restart head and worker processes, and verify that no old virtual environment, pod, notebook kernel, or long-running worker remains active. A patched package on disk does not repair a process already running vulnerable code.
4. Keep Ray in a controlled network
Ray’s security documentation says isolation must be enforced outside the cluster. Restrict dashboard and cluster ports with host, cloud, Kubernetes, VPN, and proxy controls. Do not expose Ray directly to untrusted networks, and remember that localhost binding alone does not defeat this DNS-rebinding path.
5. Enable token authentication
Ray 2.52.0 introduced built-in token authentication as an additional defense against unauthorized cluster access and untrusted code execution. Ray calls it defense in depth—not a replacement for network isolation. Verify the exact deployment documentation before enabling it across clients and clusters.
6. Preserve and inspect evidence
Before destructive cleanup, retain Ray dashboard/job logs, shell and process timelines, container and image digests, browser history where policy permits, DNS/proxy telemetry, cloud audit records, and unexpected job submissions. CISA and Ray did not publish a single universal IOC that proves or disproves compromise.
Verification matters: confirm the active Ray version from the running environment; confirm every old worker and container is gone; verify dashboards are not reachable from untrusted networks; test legitimate clients after token-auth changes; and monitor jobs, processes, and logs after rollout. Patching closes the entry point but does not remove persistence or stolen credentials from a system that was already compromised.
What developers and small businesses should take from this
This is not a consumer Windows or macOS bug that every computer owner needs to hunt for. The highest-risk audience is people and organizations using Ray for local AI development, data processing, notebooks, model training, or clustered compute. Small companies may encounter Ray indirectly in an internal AI stack, a container image, a consultant-built workflow, or a cloud notebook rather than as an application someone deliberately installed.
If you do not administer the environment, ask the platform owner three narrow questions: Are any running Ray installations older than 2.52.0? Have all active processes and images been replaced? Are dashboard/job interfaces isolated and protected with the new authentication option where supported? Avoid running public exploit demonstrations against production. Inventory, patch, isolate, preserve evidence, and verify.
Evidence matrix: confirmed, contextual, and unknown
| Question | Best-supported answer | Boundary |
|---|---|---|
| Is the flaw in CISA KEV? | Yes Added August 17; due August 20. |
KEV confirms qualifying real-world activity, not a public victim list. |
| Which versions are vulnerable? | Ray < 2.52.0 | Downstream vendors may backport fixes; verify their advisory and package provenance. |
| Can it cause code execution? | Yes The browser path can reach Ray job interfaces and execute commands in the Ray context. |
It does not automatically mean root access. |
| Was exploitation successful? | Not publicly quantified | CISA’s definition includes attempts. BitSight’s documented RondoDox attempt appeared ineffective. |
| Who is responsible? | Unattributed by CISA | RondoDox is one observed context, not a complete attribution. |
| Is ransomware involved? | Unknown | That is CISA’s explicit catalog value. |
Timeline
November 24, 2025: BitSight says its telemetry observed RondoDox attempting CVE-2025-62593; it later assessed that implementation as ineffective.
November 26, 2025: the Ray GitHub advisory and CVE record were published, identifying versions before 2.52.0 as affected and 2.52.0 as fixed.
March 11, 2026: BitSight published its broader RondoDox infrastructure analysis and the attempted-exploitation chronology.
August 11, 2026: Ray 2.57.0 was released and was the current project release at this article’s cutoff.
August 17, 2026: CISA added CVE-2025-62593 to KEV and set August 20 as the federal due date.
August 18, 2026: the CVE and NVD records reflected CISA’s exploitation enrichment; public reporting spread the urgent deadline.
Frequently asked questions
Does merely visiting a website exploit every Ray cluster?
No. The documented path requires a vulnerable Ray release, a running dashboard/job service reachable from the browser, a supported browser behavior, and attacker-controlled web content. That is serious but conditional.
Is Ray 2.52.0 enough?
It is the first fixed version named by the project. If your application supports it, use the current supported release for later fixes as well; 2.57.0 was current at our cutoff. Follow downstream vendor guidance when using a managed or backported package.
Does CISA’s “active exploitation” mean confirmed successful victims?
Not necessarily. CISA’s KEV criteria explicitly include attempted and successful exploitation. The designation means reliable evidence of real-world malicious activity and intent, not that CISA has publicly disclosed the success rate or victim identities.
Will a firewall alone fix the problem?
No. Network controls are essential, but DNS rebinding can use a developer’s browser to reach local or private services. Install the fixed Ray release and use network isolation plus token authentication as layered controls.
Should we run the public proof of concept to check?
Not on production or systems you do not own. Use package and runtime inventory, configuration and reachability checks, logs, controlled staging, and vendor guidance. Preserve evidence if compromise is suspected.
Sources and reporting method
- CISA: “CISA Adds One Known Exploited Vulnerability to Catalog” — August 17 announcement.
- CISA KEV catalog entry for CVE-2025-62593 and its machine-readable JSON feed — dates, required action, ransomware value, and notes.
- CISA: KEV criteria and meaning of active exploitation — definition of attempted and successful exploitation.
- CISA BOD 26-04 and implementation guidance — federal scope, prioritization, and forensic-response expectations.
- Ray project / GitHub advisory: “Critical RCE Vulnerability against Ray Devs exploitable via Browser” — affected versions, browser/DNS-rebinding mechanism, impact, fix, and credits. This article intentionally omits operational proof-of-concept instructions.
- CVE Program record and NVD record — authoritative description plus scoring and CISA enrichment.
- Ray security documentation — controlled-network model, trusted-code boundary, and token authentication from 2.52.0.
- Ray 2.57.0 release — current-release check at cutoff.
- BitSight: “RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities” — independent telemetry and the apparently ineffective Ray attempt.
- The Hacker News: “CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE” — August 18 independent report and same-day context.