Your Browser Should Not Be an Authentication Boundary for AI Infrastructure
A browser tab should not be able to turn a private AI development service into an internet-reachable code-execution target. That is exactly the boundary failure behind CVE-2025-62593.
CISA added the Ray vulnerability to its Known Exploited Vulnerabilities catalogue on 17 August 2026. The catalogue says the flaw is being exploited and gives US federal civilian agencies a 20 August remediation deadline. It does not describe the observed campaign, victims or exploit chain.
The vendor advisory supplies the technical context. A developer running a vulnerable Ray instance can be compromised after visiting a malicious site in Firefox or Safari. DNS rebinding can make the attacker-controlled origin resolve to a Ray service on the developer’s machine or private network. The browser then becomes a confused deputy that sends requests to an unauthenticated API capable of running code.
This is not simply another browser vulnerability. It is an AI infrastructure vulnerability that borrowed the browser’s behaviour as an authentication decision.
How an ordinary browsing action reaches Ray
Ray is a distributed computing framework used for AI, machine learning and Python workloads. Its dashboard and Jobs API are powerful by design because they coordinate work across developer machines and clusters.
The affected protection tried to distinguish browser traffic by inspecting the User-Agent header. Requests that looked like they came from a browser were rejected for sensitive methods. The assumption was that browser JavaScript could not change that header.
That assumption did not hold in Firefox and Safari. The disclosure shows that JavaScript could supply a different User-Agent, bypass Ray’s browser-request check and reach endpoints such as /api/jobs/. DNS rebinding completed the path by changing where the attacker’s hostname resolved after the page loaded.
The result is a chain with no stolen Ray password because the vulnerable endpoints did not require one:
- A developer starts a vulnerable Ray environment.
- The developer visits a malicious page or receives a malicious advertisement in Firefox or Safari.
- DNS rebinding makes the attacker’s hostname resolve to the local or network-adjacent Ray service.
- Browser JavaScript changes the header used by Ray’s request filter.
- The page submits a job through Ray’s unauthenticated API.
- Ray executes attacker-supplied shell code in the context of the Ray process.
The browser is not breaking into Ray in the conventional sense. Ray is accepting a security claim about where the request came from, and the browser is able to make that claim false.
The browser was treated as an authentication control
Cross-origin browser protections are useful, but they are not proof of identity. Origins describe where web content was loaded from. Headers describe a request. DNS describes where a name resolves at a particular moment. None of them establishes that the caller is authorised to run code on AI infrastructure.
This distinction matters because development services often begin as local conveniences. They are bound to a workstation, a container interface, a Kubernetes port or an internal address and are therefore treated as trusted. The network location becomes an informal credential.
That model fails when another trusted component can reach the service on an attacker’s behalf. A browser, extension, local application, compromised container or server-side request forgery path can all become intermediaries. “Not internet-facing” does not mean “unreachable from internet-originated activity”.
Ray’s own security guidance is unusually direct. Ray faithfully executes submitted code and does not attempt to distinguish a training job from malicious activity. The platform says isolation must still be enforced around the cluster. Starting with version 2.52.0, token authentication adds another control, but it is disabled by default and is not a substitute for a controlled network.
What is affected and what fixes it
The GitHub security advisory rates CVE-2025-62593 Critical with a CVSS 4.0 score of 9.4. Ray versions earlier than 2.52.0 are affected. Version 2.52.0 contains the fix.
Chrome was not vulnerable to the published browser path at disclosure because its implementation did not allow the same User-Agent manipulation. That should not be turned into an infrastructure mitigation. Browser behaviour changes, developers use multiple browsers, and another client can reproduce the same trust failure without looking like a browser at all.
Updating Ray closes the documented route. Enabling token authentication changes the more important design condition by requiring a shared secret for Ray APIs. Ray documents RAY_AUTH_MODE=token as the control for enabling it.
Tokens need their own protection. Ray warns that they are sent in an HTTP header and can be exposed if the connection is not encrypted. Use TLS termination, SSH or Kubernetes port forwarding, or an encrypted overlay network where appropriate. Do not expose a Ray cluster directly to the internet and assume that a token alone makes plaintext traffic safe.
What AI platform and endpoint teams should do now
Treat this as both a software-update task and an architecture review.
- Find every Ray service, not only production clusters. Include developer laptops, notebooks, CI runners, test servers, containers, Kubernetes environments and temporary GPU workstations. Development instances are central to the published attack path.
- Upgrade to Ray 2.52.0 or later. Confirm the running version after restart. A package lockfile or updated image tag is not evidence that every active process changed.
- Enable token authentication. Set
RAY_AUTH_MODE=token, manage the token as a secret and verify that clients fail closed when the token is absent. Remember that authentication remains disabled by default in 2.52.0. - Keep Ray on a controlled management path. Bind services only where needed, restrict ingress to authorised users and workloads, and avoid publishing dashboard or Jobs API ports through permissive container, cloud or Kubernetes rules.
- Encrypt remote access. Use TLS, a VPN, SSH tunnelling or controlled port forwarding. Do not send reusable Ray tokens over plaintext network paths.
- Reduce browser reach into private services. DNS rebinding protection in resolvers, host firewalls and browser local-network controls can add defence in depth. They do not replace service authentication.
- Review Jobs API activity. Investigate unexpected submissions, shell commands, runtime environments, downloads, new processes and outbound connections from Ray nodes. Pay particular attention to developer endpoints that used Firefox or Safari while a vulnerable service was running.
- Separate workloads with different trust levels. Ray does not provide a security boundary between jobs in one cluster. Use separate clusters and network controls when workloads or users should not trust each other.
CISA confirmation changes the response, not the root cause
CISA’s catalogue confirms that CVE-2025-62593 has crossed from public technique to observed exploitation. It does not tell defenders which organisations were targeted, whether the published Firefox and Safari chain was used in every case, or what attackers executed after gaining access.
Those unknowns are not a reason to delay. The affected boundary allows arbitrary code to run through a service designed to orchestrate valuable compute, data and credentials. The safe response is to update, require authentication, restrict reachability and investigate exposed systems.
The larger lesson is architectural. Browsers enforce web security rules for web content. They do not authenticate callers to AI infrastructure. If a backend can execute code, the backend must make its own authorisation decision.
