CISA has added CVE-2025-62593, a critical remote-code-execution flaw in the Ray distributed AI framework, to its Known Exploited Vulnerabilities catalog after changing its assessment from proof-of-concept availability to active exploitation on August 17, 2026. For Windows developers and administrators, the immediate task is straightforward: find any Ray installation older than version 2.52.0 and update it, especially on workstations that run Ray while their users browse the web in Firefox or Safari.

The issue matters because the vulnerable target can be a developer’s own machine rather than a traditional internet-facing server. Ray’s security advisory describes a DNS rebinding attack that can turn a visit to a malicious site—or exposure to a malicious advertisement—into code execution against a locally running Ray instance. The affected package is ray prior to 2.52.0, and the vendor’s advisory rates the issue 9.4 out of 10 under CVSS 4.0.

CISA’s August 17 catalog addition confirms that the vulnerability has crossed the agency’s threshold for known exploitation. But the public record also adds an important qualification: the specific RondoDox botnet activity cited in CISA’s updated CVE record appears to have contained an error that would stop the observed payload from bypassing Ray’s browser check. That does not make the CVE safe; it means defenders should distinguish a confirmed exploited-vulnerability designation from a public account of successful compromise by one particular botnet payload.

A Ray security upgrade mitigates DNS rebinding and protects the local dashboard from unauthorized access.Ray’s browser defense was not an authentication boundary​

Ray is an open-source framework used to distribute Python and AI workloads across one or more machines. Its dashboard and job-management functions are useful in development, testing, and shared compute environments—but older releases attempted to separate browser traffic from privileged endpoints with a check on the HTTP User-Agent header.

According to the Ray project’s GitHub security advisory, that check treated requests beginning with “Mozilla” as browser-originated and rejected them. The advisory calls the approach a weak heuristic, not real authentication. In Firefox and Safari, an attacker-controlled web page can alter the relevant header through the Fetch API, defeating the assumption behind the filter.

The second piece is DNS rebinding. In that attack pattern, a site initially resolves to an attacker-controlled server and later resolves to a private or local address, allowing browser-originated requests to reach a service that was never intended to be exposed to the public web. With Ray’s browser guard bypassed, a malicious page could issue job-related requests to a vulnerable Ray instance and execute code with the privileges of the Ray process.

The original CVE record and Ray advisory identify Firefox and Safari as the affected browsers in this scenario. Chrome is not listed as vulnerable to the same browser-side header manipulation because its behavior diverges from the Fetch specification in a way that blocks this technique. That is a narrow protection, not a reason to treat Chrome as an adequate mitigation for an unpatched Ray installation: a vulnerable service remains vulnerable to other access paths, misconfiguration, and future exploit variants.

CISA’s “active” label follows a more complicated public trail​

CISA’s alert states that its addition to the KEV catalog was based on evidence of active exploitation. The agency’s update to the National Vulnerability Database record is more revealing than the short alert: on August 17, CISA changed the CVE’s Stakeholder-Specific Vulnerability Categorization entry from “proof of concept” to “active” exploitation and attached a reference to Bitsight’s research on the RondoDox botnet.

Bitsight reported in March that RondoDox began attempting to exploit CVE-2025-62593 on November 24, 2025—two days before the CVE was published on November 26. The security firm concluded that the botnet operators were likely tracking public vulnerability research rather than waiting for formal CVE publication.

However, Bitsight also found that the RondoDox request set its User-Agent string to a value beginning with “Mozilla.” That is the exact prefix Ray’s flawed guard checks for, so the botnet’s observed exploit would have triggered the rejection it was meant to bypass. Bitsight described the implementation as ineffective.

This is the key operational detail missing from CISA’s short catalog notice. The KEV listing is a remediation priority, but it is not a public forensic report of successful RondoDox compromises. CISA’s alert does not identify victims, sectors, geographic targets, or the campaign behind the exploitation evidence. Bitsight’s evidence establishes that a major botnet attempted the vulnerability at scale, while also documenting that the observed implementation was defective.

Those facts can coexist. CISA may have evidence beyond Bitsight’s published telemetry, and a flawed RondoDox payload does not rule out successful exploitation by other actors or through a corrected payload. Administrators should not wait for public victim reporting to patch a vulnerability that CISA now classifies as actively exploited.

Windows developer workstations are the overlooked asset class​

This flaw is most dangerous where teams treat an AI or data-science environment as a local development convenience rather than an enterprise service. A Windows laptop running a Ray head node, dashboard, or local test cluster can hold browser sessions, source code, cloud credentials, SSH keys, package-manager tokens, and access to internal development services. Code execution in that context can be enough to turn a developer endpoint into an entry point for a broader compromise.

The browser requirement also breaks a common mental model in endpoint security. Teams often prioritize externally reachable vulnerabilities while assuming a localhost-bound service is insulated from web threats. DNS rebinding exists precisely to challenge that assumption: a browser can become the route from an untrusted website to a service reachable only from the user’s machine.

For organizations running Ray on Windows through Python virtual environments, Conda environments, containers, WSL, or remote development tooling, inventory cannot stop at centrally managed servers. Search CI images, developer bootstrap scripts, notebooks, internal package mirrors, requirements.txt files, pyproject.toml constraints, and golden workstation images for Ray version pins below 2.52.0.

A local check on a known Python environment is simple:

python -c "import ray; print(ray.__version__)"

Any returned version below 2.52.0 is affected. Administrators should be careful with machines that have multiple interpreters or virtual environments: checking the globally installed Python package does not establish that a project-specific virtual environment is patched.

Upgrade first, then investigate exposure​

Ray’s advisory says version 2.52.0 contains the fix. The clean remediation is to update the Ray package in every affected environment, validate that dependency-resolution tools did not retain an older version, and rebuild containers or environment images that carry the package.

For a typical pip-managed environment, the update path may resemble:

python -m pip install --upgrade "ray>=2.52.0"

That command should be adapted to an organization’s normal dependency-locking and change-control process. A direct upgrade without updating a lock file or base image can leave the next build recreating the vulnerable environment. Teams using pinned dependencies should update the pin, regenerate the lock artifact where applicable, and confirm the deployed image rather than merely the build workstation.

CISA’s revised Binding Operational Directive 26-04 applies to federal civilian executive-branch agencies, with requirements that prioritize certain KEV issues based on risk and exposure. But CISA explicitly urges all organizations to use KEV status as an input to vulnerability prioritization. Private-sector teams do not inherit the directive’s federal compliance obligations; they do inherit a clear signal that an exploit path is no longer theoretical.

Where vulnerable Ray instances may have been active since November 2025, treat patching as only the first response. Review Ray job history and dashboard access where logs exist, examine endpoint telemetry for unexpected child processes launched under Python or Ray-related service accounts, and rotate credentials that were accessible to the process if suspicious activity appears. The available public reporting does not provide a reliable, universal indicator set for successful exploitation, so incident review needs to be tied to each environment’s actual logging and access model.

The practical consequence of CISA’s action is that Ray now belongs in the same urgent remediation queue as other actively exploited software flaws. Updating to Ray 2.52.0 or later closes the documented browser-driven route; leaving an older local AI development environment in place turns ordinary web browsing into a potential code-execution event.