A browser can become a route into Ray

What has changed

On 17 August, the US Cybersecurity and Infrastructure Security Agency added CVE-2025-62593 to its Known Exploited Vulnerabilities catalogue. CISA describes the issue as code injection in Ray that may expose developers using the software as a development tool, with Firefox and Safari identified in the attack route. Inclusion in the catalogue means CISA has evidence that the vulnerability has been exploited in the wild. The agency records use in ransomware campaigns as unknown; that is not evidence for or against such use.

The underlying Ray advisory was published in November 2025, so the vulnerability itself is not new. The current development is CISA's exploitation finding. Its remediation deadline is mandatory for the US federal agencies covered by CISA's directive, not for UK companies, but the catalogue entry is a useful signal for any organisation operating the affected software.

Why a development service matters

Ray is used to run distributed computing workloads. The project says versions before 2.52.0 are affected by a weakness in the way Ray tried to distinguish browser traffic from other requests. Under the conditions described in the advisory, a developer using Firefox or Safari could visit hostile web content and have the browser used as an intermediary to reach a Ray service on the same machine or elsewhere on a network available to that browser. Successful exploitation can execute arbitrary code in the Ray environment.

This matters because a service does not have to be directly published on the internet for a browser-mediated route to reach it. A laptop, test server or internal cluster may also hold source code, cloud credentials, package-publishing access or connectivity to other systems. The advisory specifically concerns development and testing use, but teams should establish their actual deployment pattern rather than assuming that a non-production label limits the consequences.

What defenders should do

Inventory Ray installations on developer workstations, shared test hosts, build infrastructure and internal clusters. Confirm the installed package version from the running environment. The Ray project identifies 2.52.0 as the fixed release and recommends updating to that version or later. CISA tells affected organisations to apply vendor mitigations and to evaluate each asset's internet exposure.

After updating, review how Ray's management services are exposed. Bind them only where required, restrict network paths to the people and systems that need them, and avoid making a development dashboard publicly reachable. Ray 2.52.0 also introduces an authentication feature that is disabled by default, according to the advisory. Consider enabling it where compatible, but do not treat authentication as a substitute for the update or for limiting unnecessary reachability.

Where an affected service was exposed or used from a developer browser, preserve relevant host, process and network records and review them for unexpected activity. The sources confirm exploitation of the vulnerability in the wild, not that every reachable Ray instance has been compromised. Scope the review to the access and credentials available to the Ray process, and escalate through the organisation's incident process when the evidence warrants it.

• Locate Ray on workstations, test hosts, build systems and internal clusters.
• Update every affected installation to Ray 2.52.0 or later.
• Restrict management services to the minimum necessary network paths.
• Assess the new authentication option without relying on it as the sole control.
• Review evidence proportionately where an affected service was reachable.

The Beekeeper view

Development tools frequently receive production-grade trust without production-grade ownership. They run on powerful machines, accept instructions by design and sit close to credentials that make automation convenient. Calling a service internal does not explain which browsers, devices or neighbouring systems can still reach it.

Patch the known weakness, then keep the architectural lesson. A developer browser is not merely a window onto the public web; it can also be a bridge to local and private services. Those services still need an owner, a supported version, a narrow network boundary and authentication that has actually been enabled.