CISA Adds Ray Framework Flaw to KEV Catalog
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a critical vulnerability affecting Anyscale Ray to its Known Exploited Vulnerabilities (KEV) catalog, citing confirmed evidence of active exploitation in the wild. The flaw enables browser-based remote code execution (RCE), posing a serious risk to organizations running AI and machine learning workloads at scale.
Ray is an open-source, Python-native distributed computing framework widely adopted for scaling AI and machine learning pipelines. Its prevalence in data science, large language model training, and reinforcement learning environments makes this vulnerability particularly significant for the security community.
What Is Ray?
Ray provides an abstraction layer for distributing Python workloads across clusters of machines. Key components include:
- Ray Core — task and actor-based distributed execution
- Ray Serve — scalable model serving infrastructure
- Ray Train — distributed ML training
- Ray Dashboard — a browser-accessible web UI for monitoring cluster state and job execution
The Ray Dashboard is central to this vulnerability. It is exposed on port 8265 by default and, in many deployments, lacks authentication controls.
The Vulnerability
The flaw exploited in the wild relates to Ray's unauthenticated dashboard and job submission API. Attackers can submit arbitrary Python jobs through the cluster's REST API without authentication, resulting in code execution under the context of the Ray worker processes.
The "browser-based" RCE aspect refers to the ability to trigger execution via the Ray Dashboard's job submission interface — a web UI that, without network-level controls in place, is accessible to any browser reaching the cluster endpoint. Adversaries have been observed:
- Scanning for exposed Ray Dashboard ports (8265) via internet-wide scan tools
- Submitting malicious Python jobs through the unauthenticated job submission endpoint
- Using initial access to steal model weights, training data, and cloud credentials from the compromised cluster environment
- Establishing persistence within ML infrastructure for cryptocurrency mining or further lateral movement
Active Exploitation Evidence
CISA's KEV listing indicates this vulnerability has moved beyond theoretical proof-of-concept to confirmed real-world exploitation. Security researchers had flagged the Ray authentication gap as early as 2023, and Anyscale's position at the time was that the unauthenticated access was intentional — designed for trusted internal network use. However, the reality of exposed Ray clusters on the public internet has made this a persistent and actively abused attack surface.
Previous reporting from Oligo Security documented cryptomining, reverse shells, and credential theft campaigns targeting exposed Ray deployments. The CISA KEV addition signals that the severity and frequency of exploitation has reached a threshold requiring federal agency action.
Affected Configurations
Ray deployments are at risk when:
- The Ray Dashboard (port 8265) or the GCS server (port 6379) is accessible from untrusted networks
- No authentication proxy (e.g., Nginx with auth, Kubernetes ingress with auth) sits in front of the dashboard
- Firewall rules do not restrict Ray port access to trusted internal hosts
Cloud deployments on AWS, GCP, and Azure with permissive security group or firewall rules are particularly vulnerable, as are on-premises HPC clusters with flat internal network topologies.
Recommended Mitigations
Organizations using Ray should take the following immediate steps:
- Restrict network access to Ray ports (8265, 6379, 10001) to trusted internal IP ranges only
- Deploy an authentication proxy in front of the Ray Dashboard for any deployment requiring external access
- Audit existing Ray clusters for unauthorized job submissions or unexpected running actors
- Update Ray to the latest available version — newer releases include improvements to the authentication model
- Enable Ray's built-in TLS and authentication features where available (Ray 2.x introduces experimental auth options)
- Monitor for suspicious job submissions via Ray's job logs and audit tooling
Broader Implications for AI/ML Security
This incident underscores a growing pattern: AI and machine learning infrastructure often lags behind general enterprise systems in security maturity. Tools designed for trusted research environments — Ray, Jupyter, MLflow, Kubeflow — are increasingly deployed in ways that expose them to the broader internet, often without the authentication and network controls that traditional enterprise software mandates.
As AI workloads grow in business criticality, so too does the value of compromising the infrastructure running them. Organizations should apply the same security controls to ML infrastructure that they apply to production application servers.