CVE-2026-27482: Anyscale Ray Auth Bypass Vulnerability

CVE-2026-27482 Overview

CVE-2026-27482 is an authentication bypass vulnerability in Anyscale Ray, an AI compute engine. In versions 2.53.0 and below, the dashboard HTTP server blocks browser-origin POST/PUT requests but does not cover DELETE operations. Key DELETE endpoints are unauthenticated by default, allowing attackers to exploit this gap. If the dashboard or agent is reachable (e.g., configured with --dashboard-host=0.0.0.0), a malicious web page can leverage DNS rebinding or same-network access to issue DELETE requests that shut down Serve deployments or delete jobs without any user interaction.

Critical Impact

Unauthenticated DELETE endpoints in Ray's dashboard allow drive-by availability attacks, enabling remote attackers to disrupt AI workloads by shutting down services or deleting jobs without authentication.

Affected Products

• Anyscale Ray versions 2.53.0 and below
• Ray deployments with dashboard exposed (--dashboard-host=0.0.0.0)
• Ray agent HTTP servers with default configurations

Discovery Timeline

• 2026-02-21 - CVE CVE-2026-27482 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-27482

Vulnerability Analysis

This vulnerability exists due to an incomplete implementation of browser request blocking in Ray's dashboard HTTP server. While the server was designed to block mutation requests (POST/PUT) from browser origins to prevent cross-site attacks, the implementation failed to account for DELETE operations. This oversight creates a significant security gap where critical destructive operations remain accessible to unauthorized browser-based requests.

The vulnerability is particularly concerning in environments where the Ray dashboard is exposed to network interfaces beyond localhost. When configured with --dashboard-host=0.0.0.0, the dashboard becomes accessible from any network interface, making it susceptible to DNS rebinding attacks from malicious websites or direct exploitation from within the same network segment.

Root Cause

The root cause is an incomplete middleware implementation that used a blacklist approach to block specific HTTP methods (POST/PUT) rather than a comprehensive whitelist approach. The authentication middleware in http_server_agent.py and http_server_head.py only applied request restrictions to POST and PUT methods, leaving DELETE endpoints unprotected against browser-originated requests. This allowed unauthenticated DELETE operations to bypass the intended security controls.

Attack Vector

An attacker can exploit this vulnerability through DNS rebinding or same-network access when the Ray dashboard is exposed. The attack requires no user interaction beyond visiting a malicious webpage that makes DELETE requests to the Ray dashboard endpoints. Successful exploitation enables attackers to:

1. Shut down Ray Serve deployments
2. Delete running jobs
3. Disrupt AI compute workloads

The following patch demonstrates the fix implemented by adding a browser request blocking middleware to the agent HTTP server:

            dashboard_optional_utils.DashboardAgentRouteTable.bind(c)

        app = aiohttp.web.Application(
-            middlewares=[get_token_auth_middleware(aiohttp, PUBLIC_EXACT_PATHS)]
+            middlewares=[
+                get_token_auth_middleware(aiohttp, PUBLIC_EXACT_PATHS),
+                # Block all browser requests - agent is only accessed internally
+                dashboard_optional_utils.get_browser_request_middleware(aiohttp),
+            ]
        )
        app.add_routes(routes=routes.bound_routes())

Source: GitHub Commit 0fda8b8

Detection Methods for CVE-2026-27482

Indicators of Compromise

• Unexpected DELETE requests to Ray dashboard endpoints from browser user agents
• Unexplained shutdown of Ray Serve deployments or deletion of jobs
• Network traffic from external origins targeting Ray dashboard ports (typically 8265)
• DNS rebinding patterns in network logs pointing to internal Ray dashboard addresses

Detection Strategies

• Monitor Ray dashboard access logs for DELETE requests originating from browser user-agents (containing Mozilla, Chrome, Safari, etc.)
• Implement network monitoring for connections to Ray dashboard ports from unexpected source IPs
• Configure alerting for abnormal Ray Serve deployment shutdowns or job deletions
• Deploy web application firewalls to detect and block DNS rebinding attack patterns

Monitoring Recommendations

• Enable comprehensive logging for all Ray dashboard HTTP requests including method, source IP, and user-agent
• Implement real-time alerting for critical operations (service shutdown, job deletion) on Ray deployments
• Monitor for unusual network patterns indicating DNS rebinding attempts
• Regularly audit Ray dashboard configuration to ensure it's not exposed beyond intended networks

How to Mitigate CVE-2026-27482

Immediate Actions Required

• Upgrade to Ray version 2.54.0 or higher immediately
• Restrict Ray dashboard access by avoiding --dashboard-host=0.0.0.0 configurations
• Implement network segmentation to limit dashboard accessibility to trusted internal networks only
• Review and audit existing Ray deployments for exposed dashboard instances

Patch Information

The fix for this vulnerability is available in Ray version 2.54.0 and higher. The patch implements a whitelist approach to block all browser-originated mutation requests to the agent HTTP server, which is intended for internal access only. The security fix is documented in GitHub Pull Request 60526 and the GitHub Security Advisory GHSA-q5fh-2hc8-f6rq.

Workarounds

• Bind Ray dashboard to localhost only by using --dashboard-host=127.0.0.1 instead of 0.0.0.0
• Implement firewall rules to restrict access to Ray dashboard ports (default 8265) from untrusted networks
• Use a reverse proxy with proper authentication in front of the Ray dashboard
• Deploy network-level access controls to prevent external access to Ray infrastructure

# Configuration example - Bind dashboard to localhost only
ray start --head --dashboard-host=127.0.0.1

# Alternatively, use firewall rules to restrict access
# iptables example to allow only internal network
iptables -A INPUT -p tcp --dport 8265 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8265 -j DROP