CISA Gave Feds 3 Days to Patch a Ray RCE Bug That Isn't ShadowRay — What CVE-2025-62593 Means for Your CRA Article 14 Prep

On August 17, 2026, CISA added CVE-2025-62593 — a critical remote-code-execution flaw in Ray, the open-source distributed compute framework that powers a large share of Python-based ML/AI infrastructure — to its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies got until August 20, 2026 to patch: a three-day window, not the familiar two-week one. If you've seen this vulnerability described as "ShadowRay" anywhere in the last few days, that's wrong, and the mix-up is worth untangling — not as pedantry, but because the actual bug is a useful, currently-live worked example of exactly the kind of "actively exploited vulnerability" that will start triggering mandatory 24-hour reports under the EU Cyber Resilience Act's Article 14 in three weeks.

The bug CISA actually flagged

CVE-2025-62593 (GHSA-q279-jhrf-cc6v, CVSS 4.0 score 9.4) is a DNS-rebinding attack against Ray's dashboard and Jobs API. Ray's own security posture has long assumed its /api/jobs and /api/job_agent/jobs/ endpoints only get hit by non-browser HTTP clients, so its sole defense was checking whether the incoming request's User-Agent header started with the string "Mozilla" — on the (false) assumption that browsers can't be made to lie about that header. Firefox and Safari's fetch API can, in fact, set an arbitrary User-Agent. Combine that with a DNS-rebinding attack — trivial to run today with tooling like nccgroup/singularity — and a developer who simply visits a malicious site, or is served a malicious ad, while Ray's dashboard is running on their machine (default port 8265) can have arbitrary shell code executed, no interaction beyond the page load required. Chrome, ironically, is not vulnerable here — not because Google fixed anything on purpose, but because of an unrelated Chrome bug that happens to break the same header-spoofing trick.

The vulnerability was publicly disclosed on November 26, 2025, credited to Avi Lumelsky (Oligo Security, who found the header-check bypass) and Jonathan Leitschuh (who built the DNS-rebinding proof of concept while at Socket). The fix landed in Ray 2.52.0, which also — for the first time — ships a disabled-by-default token-authentication feature.

It is not ShadowRay — and the difference matters

"ShadowRay" is the name of a separate, older, and — going by exposure numbers — much larger problem: CVE-2023-48022, a missing-authentication flaw on the same Jobs API that lets an unauthenticated attacker submit and run arbitrary jobs directly, no browser trickery needed. Oligo Security's original ShadowRay research dates to March 2024; a resurgence they've tracked as "ShadowRay 2.0" has, per their own telemetry, been running since roughly September 2024 and now touches over 200,000 internet-exposed Ray servers, a portion of which are confirmed compromised. That campaign runs XMRig cryptocurrency miners against hijacked GPU clusters, a sockstress TCP-exhaustion tool for DDoS, and exfiltrates source code, databases, and AI models from compromised instances — a genuinely multi-purpose botnet. Oligo's own write-up on the 2.0 wave names CVE-2023-48022 exclusively; it does not mention CVE-2025-62593 at all.

CVE-2025-62593 is a different vulnerability, disclosed over a year and a half later, requiring a completely different attack path (a victim's browser visiting an attacker page, rather than an attacker directly hitting an exposed endpoint). Several outlets covering the August 17 KEV addition linked the two anyway, presumably because both bugs live in the same two Ray API routes and both get lazily summarized as "the Ray RCE." If your team tracks vulnerabilities by vendor advisory rather than by CVE ID, this is exactly the kind of mix-up that produces a false sense of "we already handled that" — you may have already dealt with ShadowRay's authentication gap and still be running a version vulnerable to the DNS-rebinding bug, since the fixes are unrelated.

RondoDox's exploit attempt has a bug in it

One more detail worth knowing, because it's a genuinely funny illustration of how sloppy real-world exploitation traffic can be: threat-intelligence firm BitSight reported that the RondoDox botnet began firing exploit attempts against CVE-2025-62593 on November 24, 2025 — two days before the CVE was even published — meaning RondoDox's operators were tracking the underlying vulnerability research (or the GitHub fix commit) rather than waiting for a formal CVE ID, consistent with BitSight's broader finding that RondoDox has weaponized 174 vulnerabilities since May 2025, 148 of them mapped to CVEs. But their crafted request sets its own User-Agent header to "Mozilla/5.0 (rondo2012@atomicmail[.]io)" — which starts with the literal string "Mozilla", the exact pattern Ray's (broken) defense checks for. Ray's dashboard responds to that request with HTTP 405 and refuses it. RondoDox is, as far as BitSight could tell, currently failing to exploit the vulnerability it's actively attacking, because it forgot to spoof the one header its own payload needed to omit.

That's not a reason to relax — DNS-rebinding delivery through an actual browser doesn't go through RondoDox's broken direct-request path, and CISA's KEV entry is based on real exploitation evidence, not just this one botnet's malformed attempts. It's a reminder that "actively exploited" doesn't mean every attacker executing against a KEV entry is competent, and that patching based on CVSS or KEV status is still the right call regardless of how good the observed attack traffic looks.

Why BOD 26-04 gave this three days instead of the usual fourteen

CISA's KEV program has historically run on Binding Operational Directive 22-01, which set flat remediation windows — commonly two weeks for the most severe entries. BOD 26-04, "Prioritizing Security Updates Based on Risk," replaces that flat model with a risk-tiered one: instead of CVSS score alone, agencies now get shorter windows based on a combination of confirmed exploitation, whether the affected asset is internet-facing, and whether successful exploitation hands an attacker full control of the asset. CVE-2025-62593 hit that combination — internet-reachable dashboards, full RCE outcome, confirmed in-the-wild attempts — which is why it landed in the three-day tier instead of the old default. If you track CISA KEV entries for compliance or vendor-risk purposes, BOD 26-04 is worth knowing about on its own: it means "days since KEV addition" is no longer a reliable proxy for severity the way it used to be under the old directive, and vendor risk questionnaires that still cite "CISA's standard 14-day KEV remediation window" are describing a policy that no longer applies uniformly.

What this has to do with CRA Article 14

CRA Article 14 (Regulation (EU) 2024/2847, "Reporting obligations of manufacturers") requires a manufacturer of a product with digital elements to report an actively exploited vulnerability to its designated CSIRT coordinator and ENISA — via the Single Reporting Platform established under Article 16 — within 24 hours of becoming aware of it, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure becomes available. Per Article 71, that specific obligation becomes legally enforceable on September 11, 2026, three weeks after this KEV addition. We've written the 24h/72h/14-day mechanics in detail elsewhere (linked below) — this post isn't repeating that.

What's useful about CVE-2025-62593 specifically is that it's the first genuinely current, high-severity, actively-exploited vulnerability most EU teams building on Python ML/AI infrastructure are likely to actually encounter before Article 14 goes live, which makes it a legitimate dry run rather than a hypothetical. Two things determine whether it would actually be reportable if discovered in your own stack after September 11: first, are you a "manufacturer" under the CRA for the product it's embedded in — meaning you place a product with digital elements on the EU market, as opposed to running Ray purely as an internal tool never made available to customers, which generally falls outside CRA scope; second, did you become aware that the vulnerability was being actively exploited against your specific deployment, as opposed to merely reading that it's actively exploited somewhere in general (the Article 14 clock starts on the manufacturer's own awareness, not on public KEV/advisory dates). A vendor shipping a product that bundles Ray, with a dashboard reachable from the internet, discovering exploitation attempts in their logs today, is the exact scenario Article 14 is built for — they just aren't legally required to file yet.

Since you can't file a report you don't have to file, use the three weeks before enforcement to close the gap between "we'd probably notice" and "we'd notice within 24 hours and know exactly where to send it":

• Grep your dependency manifests (requirements.txt, pyproject.toml, lockfiles, and container base images) across dev, CI, and any deployed clusters for ray versions before 2.52.0 — not just your primary service, ML/data-science tooling is frequently added outside normal procurement review.
• Confirm the Ray dashboard (default port 8265) and Jobs API are not reachable from the public internet; if they must be, put them behind authentication and a VPN or IP allowlist, not just a firewall rule someone might change later.
• Upgrade to Ray ≥ 2.52.0 and turn on the new token-authentication feature — it's opt-in, upgrading alone doesn't enable it.
• If you ship a product embedding Ray to EU customers, confirm it's listed in your SBOM (CRA Annex VII) and that you know your national CSIRT contact now — don't wait for the Single Reporting Platform to go live to find out who you'd call.
• Don't rely on "we only develop in Chrome" as a mitigation — the DNS-rebinding path specifically targets Firefox and Safari, and you don't control which browser a teammate has open.

See also

For the full CRA Article 14 reporting mechanics — the 24h/72h/14-day timeline and what each submission must contain — see CRA Article 14: The 24-Hour ENISA Serious-Incident Alert and CRA Article 14 Compliance Finale: The September 2026 Vulnerability Reporting Checklist. For why a CVE ID is not the same thing as a CRA report, see ENISA's CVE Root Just Hit 20 CNAs.

Primary sources: GitHub Security Advisory GHSA-q279-jhrf-cc6v / CVE-2025-62593 (full technical advisory, PoC, credits, fixed version, fetched via GitHub API) · Oligo Security — ShadowRay 2.0: Active Global Campaign Hijacks Ray AI Infrastructure (confirms ShadowRay 2.0 targets CVE-2023-48022, not CVE-2025-62593) · BitSight — RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities (RondoDox timeline, malformed User-Agent, exploited-CVE count) · European Commission Digital Strategy — Cyber Resilience Act: Reporting Obligations (Article 14 deadlines, Single Reporting Platform, September 11, 2026 application date) · The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE (KEV addition and remediation deadline) · SecurityAffairs — U.S. CISA Adds a Ray-Project Ray Flaw to Its KEV Catalog (BOD reference cross-check) · ComplianceHub.wiki — Ray CVE-2025-62593, KEV, BOD 26-04 (BOD 26-04 risk-tiered model explained) · Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14, 16, and 71.