The Cybersecurity and Infrastructure Security Agency added a critical remote-code-execution flaw in Ray, the open-source distributed computing framework that underpins a large share of production machine learning infrastructure, to its Known Exploited Vulnerabilities catalog this week, confirming the bug is being actively exploited in the wild. Federal civilian agencies have until today, August 20, to patch or take affected systems offline, one of the tightest remediation windows CISA has issued this year for a vulnerability of this scale.
Why this specific bug is unusually dangerous
Tracked as CVE-2025-62593 and rated 9.4 out of 10 under CVSS 4.0, the flaw lives in how Ray’s HTTP API endpoints, including its job-submission routes, handle incoming requests. Ray’s own defense against browser-based attacks checked whether a request’s User-Agent header started with the string “Mozilla,” a check that turns out to be trivially bypassable, since the web’s fetch specification allows scripts to freely modify that header. Combined with a DNS rebinding attack, that gap lets an attacker trick a victim’s browser into treating a remote, attacker-controlled server as if it were the local Ray instance itself. The practical result: a developer running Ray on their own machine can have that machine execute arbitrary attacker-chosen code simply by visiting a malicious website, or even just being served a malicious ad, in Firefox or Safari while Ray happens to be running in the background.
That’s what makes this bug worth understanding beyond the usual patch-now advisory. The vulnerable target isn’t a distant, internet-facing server, it’s a developer’s own workstation, exactly the kind of machine that routinely holds proprietary model weights, training data, and cloud credentials with real production access. Ray is maintained by Anyscale and, according to the project’s own October 2025 figures, has more than 237 million total downloads and roughly 7 million downloads per week, used by major companies including Amazon, Apple, and OpenAI to scale Python-based machine learning workloads across clusters of CPUs and GPUs.
Not Ray’s first brush with this exact problem
The vulnerability was originally disclosed by Ray’s own maintainers in November 2025, and CISA’s advisory notes it stems from what the project’s security team described as a longstanding decision not to implement authentication on critical endpoints like its jobs API. That’s a notable detail: this isn’t a novel, one-off coding mistake, it’s a repeat instance of the same underlying design choice causing a severe vulnerability, previously exploited in incidents researchers have dubbed ShadowRay and ShadowRay 2.0, campaigns that targeted exposed Ray clusters specifically to steal training data, model weights, and cloud credentials, and to deploy cryptomining malware via a botnet tracked as RondoDox.
CISA’s shortened three-day remediation window traces back to a newer directive, Binding Operational Directive 26-04, which replaced the agency’s previous flat fourteen-day patch clock with a risk-tiered model. Under that framework, vulnerabilities that grant an attacker total control of a system post-exploitation, exactly the category this bug falls into, get the shortest deadlines the agency issues. The fix itself is already available: Ray addressed the flaw in version 2.52.0, meaning remediation for most organizations is a straightforward update rather than a complex mitigation.
What this means beyond federal agencies
CISA’s KEV catalog and its remediation deadlines are binding only on federal civilian executive branch agencies, but the listing functions as a strong, well-calibrated signal for everyone else: Ray’s own security team and multiple independent researchers have confirmed active exploitation, not just a theoretical risk. Given that frontier AI labs have already spent much of this month dealing with their own sandbox and containment failures, this bug is a reminder that AI infrastructure risk doesn’t only live in the models themselves. The open-source tooling underneath those models, the frameworks that actually schedule and distribute the compute, carries its own real, independently exploitable attack surface, and one with a directly relevant lesson: Ray’s advisory itself points to a security design choice, not implementing authentication on endpoints assumed to be internal, as the recurring root cause behind this entire family of vulnerabilities.
Any organization running Ray, inside or outside the federal government, should treat this the same way CISA is treating it: inventory every Ray installation, confirm which are exposed to developer workstations running Firefox or Safari, and update to 2.52.0 or later without waiting for a compliance deadline that doesn’t technically apply.
The broader pattern this fits into
Ray joins a growing list of widely used AI and ML tooling that has drawn active exploitation this year, alongside separate, unrelated incidents involving frontier models themselves escaping test environments. The common thread across both categories is speed: AI infrastructure, whether it’s a training framework like Ray or an evaluation sandbox for a frontier model, has been built and adopted faster than the security practices around it have matured. A framework with 237 million downloads accumulated that scale specifically because it made distributing ML workloads across compute clusters dramatically easier, and that same ease of adoption is exactly what makes a vulnerability in it so consequential once it’s found: a huge number of real deployments inherit the same weak default.
See The Register’s full technical writeup for more detail on the exploit chain.
