Localhost Is Not a Firewall: DNS Rebinding, Ray, and the Local AI Services You Forgot to Secure

The Key Finding

On 17 August 2026, CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog and gave federal agencies until 20 August to fix it. Three days. That compression is worth pausing on, but it is not the interesting part.

The interesting part is who gets compromised. This is not a flaw in an internet-facing production cluster. It is a flaw that executes arbitrary shell code on a developer’s laptop — a laptop running Ray bound to localhost, behind a corporate firewall, with no inbound route from the internet — because that developer visited a web page or was served a malicious advertisement.

If your mental model of why your local development services are safe is “they are only listening on 127.0.0.1,” CVE-2025-62593 is the CVE that breaks that model. And Ray is simply the example that made KEV this week. The same reasoning applies to every local Jupyter kernel, MLflow tracking server, Ollama endpoint, vector database, Kubeflow pipeline UI and Docker daemon socket in your engineering organisation.

This post is about securing local AI development services against DNS rebinding — the technique, the reason network-level thinking misses it, and what to actually change.

Technical Analysis: How a Web Page Reaches Your Loopback Interface

The primitive: DNS rebinding

DNS rebinding is an old attack — it predates most of the infrastructure it now threatens — and it works by exploiting the gap between how the browser decides two resources share an origin and how the network stack decides where to send a packet.

The sequence:

1. A developer’s browser loads https://attacker.example. The attacker’s authoritative DNS server answers with the attacker’s real IP, and a TTL of a few seconds.
2. The page loads JavaScript. The browser now considers attacker.example a trusted same-origin context for anything served from attacker.example.
3. The script waits. The DNS record expires. The script triggers a re-resolution.
4. This time the attacker’s DNS server answers 127.0.0.1.
5. The script issues a request to http://attacker.example:8265/api/jobs. The browser believes this is same-origin — the hostname has not changed — so it does not apply the cross-origin restrictions that would normally block reading the response. The operating system, meanwhile, routes the packet to the loopback interface.

The browser has become a proxy into a network segment the attacker could never reach directly. This is the classic confused deputy: a privileged intermediary is tricked into exercising its privilege on someone else’s behalf.

Why Ray was exploitable

Ray’s maintainers were aware of browser-mediated attacks and had implemented a defence. That defence checked whether the incoming HTTP request’s User-Agent header started with the string Mozilla — on the theory that if the request looks like it came from a browser, it should be rejected.

Two problems.

First, User-Agent is attacker-influenceable in several scenarios, and the check is a string prefix comparison against a value the request originator controls. Oligo researcher Avi Lumelsky found the bypass; Jonathan Leitschuh contributed the DNS rebinding chain. Ray’s advisory (GHSA-q279-jhrf-cc6v) confirms the exploit path works against Firefox and Safari.

Second, and more fundamentally: a header check is not an authentication control. It is a heuristic that distinguishes how a request was probably made, not whether the requester is authorised. Ray’s own advisory is unusually blunt about the root cause:

“Due to the longstanding decision by the Ray Development team to not implement any sort of authentication on critical endpoints, like the /api/jobs & /api/job_agent/jobs/ has once again led to a severe vulnerability that allows attackers to execute arbitrary code against Ray.”

That word — again — matters. It is the same architectural decision that produced CVE-2023-48022 (ShadowRay), the disputed, long-unpatched RCE that Oligo has tracked into a self-replicating GPU cryptomining and DDoS botnet. Over 230,000 Ray servers are now reachable from the internet, against a few thousand when ShadowRay was first described. CVE-2025-62593 is what happens when that same trust assumption is attacked from the inside of the perimeter instead of the outside.

The lateral extension nobody is reading closely enough

Ray’s advisory contains one line that materially widens the blast radius:

the attack can also be extended to attack network-adjacent instances of Ray by leveraging the browser as a confused deputy intermediary to target Ray instances running inside a private corporate network.

The compromised endpoint is not the ceiling. Once the attacker has script execution in a browser that sits inside your network, every unauthenticated HTTP service on any RFC1918 address that browser can route to is a candidate target. A single developer visiting a malicious ad becomes a scanning and execution position inside your VPC or corporate LAN.

Impact Assessment

Risk rating: Critical for organisations running Ray development environments; high for any organisation with unauthenticated local ML tooling.

The last two rows are the operational problem. Vulnerability management programmes are scoped around production assets and internet-facing attack surface. A Ray instance a data scientist started on their laptop at 09:00 and killed at 17:00 appears in no asset inventory, is scanned by no external scanner, and generates no netflow that leaves the host. The exposure is real, actively exploited, and structurally invisible to the tooling most organisations rely on.

There is also a business-continuity dimension specific to AI workloads: development clusters routinely hold production-grade credentials. Cloud API keys for training-data buckets, model registry tokens, feature store connection strings, and increasingly LLM provider keys with meaningful spend attached. Compromising the developer machine is often a shorter path to those secrets than compromising the production estate.

The CloudShieldSecure Perspective

The reason this class of finding survives is not that the control is hard. It is that nobody owns the question.

Network security owns perimeter and segmentation, and by their model, loopback is not an exposure. Vulnerability management owns the asset inventory, and ephemeral developer services are not in it. Application security owns the code in the repository, and Ray is a dependency, not code. The service falls between three functions, all of which are individually correct.

CloudShieldSecure is built around the assumption that exposure is a property of the whole environment rather than of any single asset class. Continuous discovery covers development and test subscriptions on the same footing as production, so a Ray, Jupyter or MLflow endpoint that appears in a dev VPC is inventoried rather than ignored. Configuration monitoring flags unauthenticated services on well-known ML ports — 8265 for the Ray dashboard among them — regardless of what interface they claim to be bound to. And identity-plane visibility answers the follow-on question that actually determines impact: what credentials could that workload reach if it were executing attacker code right now?

That last question is the one worth institutionalising. A finding you cannot see is bad. A finding you can see but cannot scope is not much better.

Recommended Actions

Immediate (this week)

1. Upgrade Ray to 2.52.0 or later everywhere — including laptops, notebooks, CI runners and container base images, not only cluster nodes. Search your requirements.txt, pyproject.toml, poetry.lock and Dockerfiles for pinned Ray versions.
2. Enable Ray token authentication. Introduced in 2.52.0, it is disabled by default. Turn it on explicitly. Note its limits: tokens are stored in plaintext at ~/.ray/auth_token, they do not expire, and the dashboard caches one as a cookie for up to 30 days. Set restrictive file permissions and exclude the path from any repository or backup that leaves the host.
3. Confirm the fix is deployed before the KEV deadline if you are an FCEB agency or a supplier contractually bound to KEV timelines.

Structural (this quarter)

4. Stop treating loopback binding as a control. Put authentication on every local development service, or front it with an authenticating proxy. 127.0.0.1 limits which hosts can route to you; it does not limit which origins can reach you through a browser on that host.
5. Add DNS rebinding protection at the resolver. Most enterprise resolvers and many local ones can drop external DNS answers that resolve to private or loopback address space. This is a single configuration change that mitigates an entire attack class, including for services you have not inventoried yet.
6. Inventory the shadow ML stack. Ray (8265), Jupyter (8888), MLflow (5000), Ollama (11434), TensorBoard (6006), Kubeflow, local vector stores. For each, record: does it authenticate by default, and does anyone own patching it?
7. Scope developer machines into your credential blast-radius model. If a laptop can execute attacker code, treat every credential cached on it as reachable. Prefer short-lived, federated credentials over long-lived keys in local config files.
8. Retire User-Agent-style heuristics wherever you find them in your own code. A request-shape check is not an authorisation decision. If a control can be defeated by setting a header, it was documentation, not security.

Sources & References

• CISA — CISA Adds One Known Exploited Vulnerability to Catalog (17 Aug 2026)
• Ray Project Security Advisory GHSA-q279-jhrf-cc6v (CVE-2025-62593)
• The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE
• The Register — CISA gives feds 3 days to fix actively exploited Ray RCE bug
• Oligo Security — ShadowRay: First Known Attack Campaign Targeting AI Workloads
• The Hacker News — ShadowRay 2.0 Exploits Unpatched Ray Flaw to Build Self-Spreading GPU Cryptomining Botnet
• Ray Documentation — Token authentication
• Ray Documentation — Security
• GitHub Advisory Database — CVE-2025-62593

CloudShieldSecure is a cloud security platform from CloudKonsult Limited. Learn more at cloudshieldsecure.cloudkonsult.cloud.