CVE -2025-62593 allows remote code execution in development environments that use Ray, the framework for artificial intelligence workloads. The attack can be launched from a malicious website or advertisement, when the developer is using Firefox or Safari.

The issue affects Ray versions prior to 2.52.0. The project's technical team has published an updated version and a detailed description of the attack, as the vulnerability is not limited to a simple interface error: it can lead to the execution of arbitrary commands on the developer's machine.
See also: Critical vulnerability in GitLab allows deletion of projects
How are artificial intelligence applications affected?
Ray typically launches a control panel on port 8265, from where jobs are created and monitored. The vulnerability lies in the assumption that requests from a browser will have a User-Agent starting with "Mozilla". This indication is used as a rough filter to reject requests to critical parts of the panel.
According to Ray's official security advisory on GitHub, Firefox and Safari allow modification of the User-Agent header via the Fetch API. An attacker can thus combine DNS spoofing, known as DNS rebinding, with a request to the local or internal Ray.
If the developer visits the malicious page or sees the ad, the browser can act as an intermediary to a service that is not directly accessible from the internet. The request reaches unauthenticated APIs, such as /api/jobs/, and submits a job with shell commands. In this way, CVE-2025-62593 can be transformed into full code execution.

The impact for AI teams
The CVE entry classifies the issue as critical and reports a CVSS 4.0 score of 9.4. The attack requires user interaction, but does not require a Ray account, and its success could impact the confidentiality, integrity, and availability of the system.
The risk is greatest in labs running machine learning experiments on shared computers, internal networks, or development servers. A Ray listening on a wider network interface could give a malicious page access to infrastructure that was considered internal, even if it is not published directly to the internet.
The attack doesn’t necessarily require installing a file or clicking a link within the Ray app. It simply requires loading a page in the appropriate browser so that the page’s code attempts to communicate with the service. For this reason, teams need to consider not only the server settings, but also how developers’ workstations are used.
The fix isn't just a change to browser checking. The project added additional checking for Sec-Fetch-*, and version 2.52.0 also offers a token authentication mechanism. The GitHub advisory notes that authentication is disabled by default, so it needs to be explicitly enabled by an administrator.
See also: Vulnerability in VMware vCenter exploited

Immediate protective actions for the Ray vulnerability
Administrators should upgrade the Ray package to 2.52.0 or later and enable token authentication, following the Ray security documentation. In addition, port 8265 should be restricted with firewall rules and only accessible by necessary administrators.
Until the upgrade is complete, avoid running the dashboard on a public or non-isolated interface, restrict access to the local system, and review recent requests to the task APIs. The SecNews technical team also recommends isolating development environments from production data and re-verifying credentials located on the same machines.
See also: New Linux botnet turns devices into SOCKS5 proxies
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
CVE -2025-62593 shows that a local AI tool should not be treated as a harmless development service. Installing the patched version, enabling authentication, and strict network segmentation significantly reduce the likelihood of exploitation.
