CISA has added a critical Ray vulnerability, CVE-2025-62593, to its Known Exploited Vulnerabilities catalog after confirming active exploitation. The issue matters beyond traditional server patching because the exploit path can start in a developer's browser: a malicious website or advertisement can abuse DNS rebinding and weak browser-origin defenses to reach a locally running Ray service and trigger remote code execution.

Ray is widely used to scale Python, AI, machine learning, and data-processing workloads. That makes this advisory especially relevant for engineering teams, research groups, MLOps platforms, and organizations that allow developers to run local dashboards or distributed compute tooling on workstations. When a flaw in a developer tool can be reached through routine web browsing, the exposure window is not limited to internet-facing servers.

What CISA flagged

CISA's KEV listing means the agency has evidence that CVE-2025-62593 is being exploited in the wild. The vulnerability carries a CVSS score of 9.4 and affects Ray before the fixed Python package release. According to the original reporting and the Ray security advisory, the bug can enable remote code execution through browsers such as Mozilla Firefox and Apple Safari when paired with DNS rebinding.

DNS rebinding is a technique that lets an attacker-controlled domain first resolve to an external address and then, after browser trust has been established, resolve to an internal or local address. If a local service trusts requests based on assumptions about origin, host headers, or browser behavior, the attacker's web page may be able to interact with that service as if it were a same-origin or locally permitted client.

In this case, the core weakness is insufficient protection against browser-based attacks, including scenarios involving a modified User-Agent header. The practical risk is that a developer running Ray locally could visit a hostile page, or simply receive a malicious advertisement, and the browser could become the bridge to the Ray process.

Why this is serious for AI and data teams

Security teams often focus on production infrastructure, exposed APIs, and cloud control planes. CVE-2025-62593 is a reminder that developer workstations and research environments are part of the attack surface. Ray is commonly used in experimental AI workflows, notebook-adjacent development, distributed model training, and internal compute clusters. These environments often contain credentials, source code, datasets, SSH keys, cloud tokens, and access to internal networks.

A browser-triggered path to code execution can bypass some traditional assumptions. The Ray service does not necessarily have to be advertised to the internet for the developer to be at risk. If the vulnerable service is reachable from the browser on localhost or a private interface, a web-delivered attack may still be viable.

That makes this vulnerability important for organizations adopting AI and ML tooling quickly. Developer convenience features, dashboards, and local orchestration endpoints should be treated with the same care as administrative web interfaces.

Immediate actions to take

The most important step is to upgrade Ray to version 2.52.0 or later, where the issue has been addressed. Teams should validate both workstation and server-side installations, including virtual environments, container images, notebooks, CI runners, MLOps images, and shared development hosts.

Recommended response steps:

- Inventory Ray usage across developer machines, research servers, notebooks, CI pipelines, and container registries.
- Upgrade the Ray Python package to version 2.52.0 or newer.
- Rebuild and redeploy container images that include Ray, rather than only patching running hosts.
- Restrict Ray dashboards and control services to trusted interfaces only.
- Avoid exposing local development services on broad network bindings such as 0.0.0.0 unless strictly required.
- Use host firewalls or endpoint controls to limit browser access to sensitive local services where possible.
- Review proxy, VPN, and split-tunnel configurations that may make internal services reachable from a browser session.
- Treat suspicious browser activity on developer systems as potentially relevant to endpoint compromise.

Federal Civilian Executive Branch agencies have been directed to apply fixes or mitigations by August 20, 2026. Private-sector organizations should not treat that as a distant deadline; the KEV designation indicates exploitation is already occurring.

Detection and investigation guidance

Defenders should look for evidence that Ray processes received unexpected HTTP requests from browsers or from unusual local origins. Logs may vary depending on how Ray is deployed, but useful signals can include unexpected dashboard access, unusual User-Agent values, requests arriving shortly after visits to unfamiliar websites, or command execution spawned from Ray-related processes.

Endpoint detection teams should also review child processes launched by Python, Ray, or notebook runtimes. A browser-delivered attack that reaches a local Ray process may ultimately appear as suspicious process creation, network connections, file writes, credential access, or script execution under a developer account.

Because developer workstations often have high-value access, incident responders should assume possible token exposure if exploitation is suspected. Rotate exposed cloud credentials, revoke active sessions where necessary, and review recent source control, package registry, and infrastructure activity linked to the affected user.

Longer-term hardening lessons

This advisory reinforces a broader lesson: local developer services are not automatically safe just because they bind to private or loopback addresses. Browsers are powerful cross-boundary execution environments, and DNS rebinding continues to be a reliable way to challenge weak trust assumptions.

Engineering teams should require authentication and origin protections for local dashboards, avoid unauthenticated administrative endpoints, and document which developer tools open local web ports. Security reviews for AI platforms should include the workstation path, not just hosted inference endpoints and production clusters.

For organizations building AI capability at speed, the best control is disciplined asset management: know where frameworks like Ray are installed, update them quickly, and avoid leaving experimental services running longer than necessary.

Source: The Hacker News source