On 17 August 2026, CISA added a single vulnerability to the Known Exploited Vulnerabilities catalog: CVE-2025-62593, a code injection flaw in Ray, the open-source distributed compute engine that underpins a very large share of production machine learning training and inference infrastructure.

The remediation due date for Federal Civilian Executive Branch agencies is 20 August 2026 — three days.

The compressed timeline reflects BOD 26-04, “Prioritizing Security Updates Based on Risk,” which replaced the flat fourteen-day KEV remediation clock with a risk-tiered model. Vulnerabilities on publicly exposed assets that grant total control of the asset post-exploitation get the shortest deadlines. Ray qualifies on both counts. We covered the directive’s mechanics when its first tranche of deadlines landed on 7 August.

The vulnerability

CVE-2025-62593 affects Ray versions before 2.52.0 and carries a CVSS 4.0 score of 9.4. It is a failure of protection against browser-based attacks on the Ray dashboard and API.

The mechanism is worth reading carefully, because it is a small architectural mistake with an unusually large blast radius.

Ray exposes HTTP API endpoints — including /api/jobs and /api/job_agent/jobs/ — that submit and execute code on the cluster. That is Ray’s purpose: it is a distributed execution engine, and submitting code for execution is the product.

Ray’s defence against a malicious website reaching a locally running Ray instance was a check on whether the HTTP User-Agent header started with “Mozilla.” The reasoning: requests from a browser carry a Mozilla-prefixed User-Agent, and Ray does not want to accept job submissions from browsers, so reject those.

Browsers can modify that header. Combine that with DNS rebinding — where an attacker-controlled domain resolves first to the attacker’s server and then to 127.0.0.1, defeating same-origin protections at the network layer — and a website can reach a Ray instance on the victim’s own machine and submit code to it.

The practical consequence: a developer who visits a malicious website, or merely views a malicious advertisement, while running Ray locally can have arbitrary code executed on their machine. No credential theft, no phishing, no user interaction beyond loading a page.

Ray addressed this in version 2.52.0.

Why a User-Agent check was ever the control

It is easy to be dismissive about a security control that trusts a client-supplied header. It is more useful to understand why it happened, because the same reasoning is present in a great deal of AI infrastructure.

Ray was built as a cluster compute framework for trusted networks. In the environment its designers had in mind — a research cluster or an internal ML platform behind an enterprise perimeter — the code submission endpoint is not a vulnerability, it is the API. Authentication was not a design goal because the network boundary was the authentication.

The User-Agent check was not intended as a security boundary against a determined attacker. It was intended to stop an accidental interaction: a developer’s browser stumbling into the dashboard API. It was a usability guard that ended up standing where a security control was needed, because the deployment reality drifted away from the design assumption.

That drift is the general pattern in AI infrastructure. This tooling was overwhelmingly built by research organisations for research environments, optimised for iteration speed, and then adopted into production and onto developer laptops without the perimeter its threat model presumed. We saw the same shape in the Langflow CVE-2026-9198 KEV addition earlier this month: an AI orchestration tool whose design assumed a trusted network, exposed, and carrying credentials to everything it orchestrated.

The real problem is inventory

For most organisations, patching Ray is easy. Finding Ray is not.

Ray is not typically procured. It arrives as a transitive dependency, a base image layer, a component of a managed ML platform, or a pip install on a data scientist’s laptop. It appears in at least six places that are usually inventoried by six different processes, or by none:

Developer workstations. This is the vector the CVE actually describes, and the least governed environment in most organisations. A data scientist running ray start --head locally to test a training job has an exposed code execution endpoint on their machine, and no asset management system knows about it.

CI/CD runners. Ray in a test pipeline runs with pipeline credentials, which are typically expansive — registry access, cloud credentials, deployment rights.

Container images. Ray inside a base image inherited from a platform team, or from a public ML image, appears in an SBOM only if you generate SBOMs for base layers, which many organisations do not.

Kubernetes workloads. KubeRay deployments, often managed by a platform or ML team operating outside the standard change management process.

Cloud data processing clusters. Managed services that embed Ray, where the version is the provider’s responsibility until it is yours.

Vendor products. Third-party ML platforms that ship Ray internally. You may have no visibility into the version at all, and no contractual right to require an upgrade on a three-day timeline.

The organisations that will meet the 20 August deadline are not the ones with the fastest patching. They are the ones that can answer the question “where is Ray?” in under a day. That is an inventory capability, and it is the one AI infrastructure has most consistently escaped.

What BOD 26-04 signals beyond the federal perimeter

BOD 26-04 binds FCEB agencies. It does not bind private organisations. It matters to them anyway, for three reasons.

It is becoming the reference standard. KEV membership has already migrated into contract language, cyber insurance questionnaires, and regulatory examination scope well beyond federal civilian agencies. Once a directive establishes that a certain class of vulnerability warrants a three-day response, that becomes the benchmark against which “reasonable” is measured — in an FTC Section 5 unfairness analysis, in a state AG investigation, in a negligence claim, and in a NIS2 Article 21 supervisory review.

It rejects CVSS-only prioritisation. The directive’s core move is that severity scores alone are the wrong input. What matters is exploitation status, exposure, and post-exploitation impact. Organisations still running a “patch criticals in 30 days, highs in 90” policy keyed to CVSS are applying a model the federal government has formally abandoned. That policy will patch a CVSS 9.8 flaw in an unreachable internal service on the same timeline as an actively exploited, internet-facing, total-control vulnerability.

Three days is a capability test. A three-day window admits no CAB meeting, no monthly maintenance window, no waiting for a vendor’s next scheduled release. Meeting it requires pre-existing emergency change authority, a current and queryable asset inventory, and an owner who can be reached. Most organisations discover they lack one of the three during the incident rather than before it.

The AI infrastructure pattern

Three AI-adjacent tools have now entered the KEV catalog in recent months — Langflow, Ray, and related orchestration components — and researchers at DEF CON 34 this month disclosed ten vulnerabilities in llama.cpp, including two llama-server issues rated 9.2, plus four Pyodide sandbox escape CVEs scoring 8.3 to 9.9 across seven products.

The shared characteristics are consistent enough to be predictive:

  • Designed for trusted networks, deployed on untrusted ones.
  • Code execution is the intended function, so the boundary between feature and vulnerability is thin and depends entirely on access control.
  • Authentication is optional or absent by default, because the design assumed a perimeter.
  • Adopted bottom-up by data science and ML teams, outside the procurement and architecture review processes that would have caught the exposure.
  • Holds credentials to everything — object storage, model registries, feature stores, production inference endpoints.
  • Poorly inventoried, because it does not look like an application to asset management and does not look like infrastructure to application security.

Treat this as a category, not a series of individual CVEs. The next one is coming, and the organisations that handle it well will be the ones that did the inventory work now rather than during the next three-day window.

What to do

This week

  1. Find Ray. Query workstation endpoint management for the ray Python package. Search container registries and SBOMs. Check Kubernetes for KubeRay operators and Ray clusters. Grep CI configurations. Ask your ML platform vendors in writing.
  2. Upgrade to 2.52.0 or later everywhere you find it.
  3. Where you cannot upgrade immediately, ensure the Ray dashboard and API are not reachable from a browser context — bind to localhost only where the workload permits, and place authenticating proxies in front of any cluster dashboard.
  4. Confirm no Ray dashboard is internet-exposed. Check from outside your network, not from your firewall rules.

This quarter

  1. Build an AI infrastructure inventory as a distinct asset class: compute frameworks, orchestration tools, vector databases, model servers, notebook environments, agent frameworks. Record version, owner, network exposure, and credentials held.
  2. Bring developer workstations into vulnerability management scope for AI tooling. The Ray CVE’s primary victim is a laptop, and most VM programmes stop at the server boundary.
  3. Rewrite your patch policy around exploitation status and exposure, not CVSS bands. Align the top tier with BOD 26-04’s logic even though the directive does not bind you.
  4. Establish emergency change authority that can execute inside 72 hours without a scheduled board.
  5. Add AI infrastructure to third-party risk questionnaires. Ask vendors which frameworks their platform embeds and what their remediation SLA is for KEV-listed components.

Ongoing

  1. Subscribe to KEV additions as an operational feed with a defined triage owner, not a newsletter.
  2. Include AI infrastructure in penetration test scope explicitly. It is routinely excluded because it is classified as a data science environment rather than an application.
  3. Require authentication as a default-deny property on every internal service, including the ones whose documentation says authentication is optional.

Closing

The technically interesting part of CVE-2025-62593 is that Ray’s protection against browser-originated code execution was a check on whether the client claimed to be a browser. It is a good reminder that a control which relies on the client telling the truth is not a control.

The operationally important part is that CISA gave federal agencies three days to remediate a component that most organisations cannot locate in three weeks. AI infrastructure has been adopted faster than it has been inventoried, it holds credentials to the most valuable data in the enterprise, and it was largely designed for a network perimeter that no longer exists around it.

The patch is straightforward. Build the inventory before the next one, because the next one will also come with a three-day clock.

This article is provided for informational purposes only and does not constitute legal advice. Organisations should consult qualified counsel and appropriate technical advisors regarding their specific vulnerability management obligations.