What happened
On 26 November 2025, the Ray Project published the original maintainer advisory for CVE-2025-62593. The defect allows a hostile website or malicious advertisement to use a developer’s browser as a route to a locally or network-reachable Ray dashboard. On 17 August 2026, CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalogue based on evidence of active exploitation. CISA set 20 August 2026 as the federal remediation due date for CVE-2025-62593. That authoritative change is the reason the older vulnerability leads today’s edition.
CVE-2025-62593 affects Ray versions earlier than 2.52.0; Ray 2.52.0 is the patched baseline. The affected control surface includes the unauthenticated /api/jobs and /api/job_agent/jobs/ endpoints. The exposed Ray Dashboard service uses TCP port 8265 by default. Firefox and Safari are the browsers the maintainer advisory identifies as enabling the User-Agent bypass; Chrome is not identified as vulnerable to that step. The maintainer advisory demonstrates the DNS-rebinding path with NCC Group’s Singularity proof-of-concept framework.
Ray is the affected distributed AI compute framework. No underlying AI model or version was identified in the cited sources. Exposure depends on developers running Ray before 2.52.0 with browser-reachable dashboard endpoints and insufficient authentication controls. Mechanically, the exploit uses DNS rebinding and a modifiable User-Agent header to submit a job that Ray executes with the Ray process’s privileges. The issue concerns the framework’s control surface; it is not evidence that an AI model selected targets or initiated exploitation.
No exploit hashes, malicious domains, IP addresses or named malware artefacts were published in the cited sources. Defenders must therefore hunt through software versions, dashboard reachability, Ray job submissions, process ancestry, shell execution and access to secrets rather than relying on a fixed indicator list. Attribution posture: CISA’s KEV entry names no actor behind the observed exploitation. Upgrade affected Ray deployments to version 2.52.0 or later.
Why this matters now
The important change is exploitation status, not a new severity score. An issue that could previously sit in a conventional remediation queue now requires teams to assume that real adversaries have a working path and to test whether their own browser, network and dashboard configuration supplied the required conditions. A package upgrade alone cannot answer that question.
Ray often sits outside traditional production-server inventories because developers launch it locally, in notebooks, ephemeral test clusters or AI engineering environments. Those locations can still hold source-code access, cloud tokens, model artefacts and data-platform credentials. The combination of weak inventory and privileged developer context can make the practical blast radius greater than the apparent number of persistent servers.
The browser-assisted attack path also challenges perimeter-based exposure assumptions. A Ray dashboard does not need to be directly internet-accessible if a developer’s browser can reach it after visiting hostile content. Vulnerability owners must therefore combine software inventory, local network reachability, browser paths and job-history evidence rather than limiting review to external scanners.
The decision for security leaders
Assign AI platform engineering and endpoint security a single inventory deadline covering laptops, build workers, notebooks, containers and clusters. Traditional server CMDBs are unlikely to represent the full Ray footprint, and unowned experimental deployments must be treated as unresolved exposure rather than accepted absence.
Separate remediation from compromise assessment. Version 2.52.0 removes the disclosed path, but leaders need a documented review of job submissions, shell execution, outbound connections and credentials available to each exposed process before closing the risk. Positive findings belong in incident response, not the patch programme.
Treat Ray’s dashboard and job interfaces as privileged control-plane services. Require authentication, network restriction, logging and explicit ownership even after upgrading. The incident demonstrates that developer-only interfaces can become remotely reachable through a browser without appearing on an internet-exposure scan.
Evidence of closure
- Software inventory shows no Ray version earlier than 2.52.0.
- Network testing proves port 8265 is unreachable from untrusted browser paths.
- Ray job logs show no unauthorised submissions during the review window.
- Incident response records an approved disposition for every exposed instance.
The Security.io assessment
CISA’s KEV decision supplies high-confidence evidence that exploitation is occurring, but the public record does not describe victims, actor infrastructure or post-exploitation tradecraft. That limits indicator-led hunting and makes local telemetry decisive. Organisations lacking Ray job-history retention should record that evidentiary limitation rather than equating an absence of alerts with an absence of compromise.
The attack’s practical relevance depends on configuration and workflow: an affected Ray version must be reachable from the browser path, and the Ray process’s privileges determine consequence. Developer environments often combine broad repository access, cloud credentials and relaxed network controls, making configuration context more useful than a generic asset criticality rating.
The narrow deadline is justified because inventory uncertainty can consume most of the available response window. The first leadership question is not whether Ray is formally approved; it is whether the organisation can prove that affected packages and running processes do not exist outside approved AI platforms.
Questions for the morning meeting
- Can the organisation identify every Ray deployment, including developer laptops and temporary AI environments?
- Which Ray processes could access cloud credentials, source repositories or production data?
- What evidence distinguishes successfully patched Ray instances from instances that were never exploited?