Ray CVE-2025-62593: How DNS Rebinding Enables Browser-Based RCE

A critical vulnerability in Ray shows how ordinary web browsing can create an unexpected path into AI development infrastructure. CISA has added Ray CVE-2025-62593 to its Known Exploited Vulnerabilities (KEV) catalog based on evidence of active exploitation. The flaw affects Ray, an open-source Python framework used to scale AI and machine-learning workloads.

What makes this vulnerability unusual is its attack path. An attacker does not necessarily need direct network access to a Ray instance. Instead, DNS rebinding can turn a developer’s browser into an intermediary for reaching Ray services on a local machine or private network.

CVE-2025-62593 is a Ray vulnerability rated 9.4 Critical under CVSS v4.0 that combines DNS rebinding with insufficient browser-request protections. The documented attack can reach vulnerable Ray services and lead to arbitrary code execution. CISA has confirmed evidence of active exploitation, while Ray 2.52.0 contains the security fix.

CVE-2025-62593 at a glance

Why CISA added CVE-2025-62593 to KEV

Ray is a Python-native distributed computing framework designed to scale AI and machine-learning workloads. Developers can run Ray locally for development and testing or deploy it across distributed infrastructure.

CVE-2025-62593 affects Ray versions before 2.52.0. The vulnerability involves protections intended to prevent browsers from making dangerous requests to Ray’s dashboard services.

Those protections could be bypassed.

Ray used User-Agent handling to distinguish browser-generated traffic. Requests identified as browser traffic could then be rejected from sensitive operations.

However, the documented technique can manipulate the User-Agent value in Firefox and Safari. Combined with DNS rebinding, this can allow attacker-controlled web content to send requests toward a Ray service accessible from the victim’s environment.

CISA’s KEV listing raises the operational priority of the vulnerability. It confirms evidence of exploitation in the wild rather than merely the existence of a proof of concept.

However, CISA has not publicly detailed the incidents behind the KEV listing.

How DNS rebinding turns a browser into a path to Ray

The distinctive element of CVE-2025-62593 is that the vulnerable Ray service does not necessarily have to be directly reachable from the internet.

The attack instead uses the victim’s browser as an intermediary.

First, a developer visits attacker-controlled web content. This could be a malicious website or other attacker-controlled content loaded by the browser.

The attacker controls the DNS records associated with a domain used by that content. Initially, the domain can resolve to attacker-controlled infrastructure.

The DNS response can later change so that the same hostname resolves to an address accessible from the victim’s environment. That destination could be a Ray service running locally or elsewhere on a reachable private network.

The browser can therefore provide a path between attacker-controlled web content and a service that the attacker cannot directly reach.

Ray’s browser-request handling contributes to the attack. In the documented exploitation path, Firefox and Safari allow a manipulated User-Agent value that can cause browser-generated requests to bypass Ray’s intended browser-traffic check.

The proof-of-concept attack can then submit requests to sensitive Ray functionality. Successful exploitation can ultimately result in arbitrary command execution with the privileges available to the Ray process.

Why Firefox and Safari matter

Ray attempted to identify browser traffic by checking whether the User-Agent header began with Mozilla. However, the documented attack showed that Firefox and Safari allowed JavaScript using fetch() to set a custom User-Agent value. An attacker could therefore make browser-generated requests bypass Ray’s check.

Chrome does not follow the same documented exploitation path because its handling prevents this particular User-Agent manipulation.

However, changing browsers is not a remediation for an affected Ray installation. Organizations should upgrade the vulnerable Ray environment.

Why private Ray environments can still be exposed

Security teams often prioritize internet-facing services because external attackers can reach them directly.

CVE-2025-62593 demonstrates why that distinction is not always sufficient.

A Ray service running on a developer workstation may not be publicly exposed. However, a developer’s browser may be able to reach local or private-network services accessible from that endpoint, allowing DNS rebinding to create a path to a vulnerable Ray service under the documented conditions.

DNS rebinding can take advantage of that position.

The same principle can apply to network-adjacent Ray services accessible from the developer’s environment. As a result, private-network placement alone should not be treated as protection against this attack path.

This makes developer workstations particularly important when assessing exposure. They combine ordinary internet browsing with access to development tools, test systems and internal AI infrastructure.

Organizations should therefore include developer endpoints when identifying vulnerable Ray installations. The assessment should not stop at public-facing servers or production clusters.

What active exploitation confirms, and what remains unknown

CISA’s KEV listing confirms evidence of active exploitation of CVE-2025-62593.

However, that does not reveal how every observed attack exploited the vulnerability.

CISA has not publicly identified a threat actor, campaign or specific victim profile associated with its KEV decision. It has also not publicly described whether the observed attacks used the same browser-based sequence demonstrated in the proof of concept.

Organizations should therefore avoid assuming an attacker profile or exploitation objective that has not been confirmed.

The established facts are more limited: the vulnerability can enable code execution, a documented browser-based exploitation technique exists, and CISA considers the vulnerability actively exploited.

Ray 2.52.0 fixes CVE-2025-62593

Organizations running affected Ray versions should upgrade to Ray 2.52.0 or later.

The fixed release addresses CVE-2025-62593. Organizations should also review the authentication and network controls surrounding their Ray deployments rather than relying only on network location for protection.

Security teams should first determine where Ray is running. The inventory should cover:

• Developer laptops and workstations
• AI and machine-learning testing systems
• Internal Ray clusters
• Data science environments
• Shared development infrastructure

Teams should then review whether Ray dashboards and APIs are reachable from unnecessary systems or network segments.

If exploitation is suspected, security teams should investigate affected endpoints for unexpected process execution, shell commands and network activity associated with Ray or its underlying Python processes.

Featured resource

Why XDR Is Stronger With UEM

Discover how combining UEM and XDR strengthens endpoint security by bringing proactive device management and threat investigation and response into a more unified security approach.

Download the whitepaper

Reducing endpoint exposure around vulnerable Ray environments

CVE-2025-62593 crosses an unusual security boundary. The initial interaction occurs in a web browser, while successful exploitation can result in code execution through a reachable Ray service.

That makes the developer endpoint relevant alongside the vulnerable application itself.

Hexnode UEM: Manage the developer endpoint posture

Hexnode UEM can support configuration and patch management across managed developer endpoints.

For Windows devices, IT teams can manage supported operating system and application updates and review application update status from the Hexnode UEM console. Across managed Windows and macOS devices, administrators can apply supported policies and restrictions to maintain endpoint configurations.

These controls can help organizations maintain the broader security posture of developer workstations that access Ray environments.

Ray should be upgraded to version 2.52.0 or later through the package-management or software-deployment workflow used by the organization. Where appropriate, administrators can use supported Hexnode UEM scripting capabilities to execute custom administrative scripts on managed endpoints. Organizations should not treat general endpoint patch management as a substitute for applying the Ray security fix.

Hexnode XDR: Investigate suspicious execution on Windows and macOS endpoints

If exploitation is suspected on a supported Windows developer endpoint, Hexnode XDR can support endpoint investigation and response.

Security teams can use Hexnode XDR’s threat-hunting and investigation capabilities to examine endpoint data for suspicious activity associated with browsers, Python processes, or other processes involved in a suspected compromise.

Where malicious activity is identified, available response actions include device isolation, malicious process termination, and file quarantine.

These capabilities address the endpoint investigation and response side of the incident. They do not replace patching vulnerable Ray installations or restricting unnecessary access to Ray services.

What enterprises should do about CVE-2025-62593

Organizations using Ray should prioritize remediation because CISA has confirmed evidence of active exploitation.

Security, development and IT teams should:

• Identify Ray installations across developer endpoints, testing systems and AI infrastructure.
• Upgrade affected installations to Ray 2.52.0 or later.
• Review whether Ray dashboards and APIs are unnecessarily reachable across network segments.
• Review authentication and access controls protecting Ray deployments.
• Include developer workstations when assessing exposure to the vulnerability.
• Investigate systems that ran vulnerable Ray versions where exploitation is suspected.
• Review unexpected processes, commands and network activity associated with Ray or Python.
• Maintain appropriate security configurations and software-update practices on developer endpoints.

Most importantly, organizations should not classify a Ray instance as low risk simply because it runs on localhost or a private network.

CVE-2025-62593 changes the security boundary around Ray

Ray CVE-2025-62593 demonstrates how web browsing and internal AI infrastructure can become part of the same attack path.

A service does not necessarily need to be publicly exposed for attacker-controlled web content to reach it. DNS rebinding can take advantage of a browser’s existing access to local and private-network resources.

CISA’s KEV listing makes remediation a priority. Organizations should identify vulnerable Ray installations, upgrade to Ray 2.52.0 or later, review service exposure and investigate developer endpoints where compromise is suspected.

For AI development teams, the central lesson is straightforward: localhost and private-network placement alone do not eliminate browser-mediated attack paths.