Ray Dashboard Unauthenticated Job Deletion (CVE-2026-27482)

Executive Summary

What: A medium-severity authentication bypass vulnerability (CVE-2026-27482, CVSS 6.5) in the Ray AI compute engine's dashboard HTTP server permits unauthenticated remote attackers to delete running jobs and shut down Serve applications via unprotected DELETE endpoints (NVD). The dashboard's middleware blocks browser-origin POST and PUT requests but omits DELETE, leaving three critical API paths exposed without authentication (GHSA-q5fh-2hc8-f6rq).

So What: Organisations running Ray versions 2.53.0 and below with the dashboard exposed to the network are vulnerable to availability disruption. The attack path includes DNS rebinding from a malicious webpage, meaning even dashboards bound to internal interfaces may be reachable if an internal user visits a crafted URL (GHSA-q5fh-2hc8-f6rq). Because dashboard token authentication is optional and disabled by default, deployments with token authentication left disabled remain exposed. Impact is confined to availability — running AI training jobs can be terminated and Serve inference applications shut down entirely, with in-progress computation lost if not checkpointed (NVD).

Now What: Upgrade to Ray 2.54.0 immediately. Restrict dashboard network exposure to authorised administrators. Enable dashboard token authentication on all deployments where it is currently disabled. Audit all Ray clusters for dashboard bindings on network-accessible interfaces (e.g., 0.0.0.0) (RAXE assessment).

Risk Rating

CVSS Divergence Note: NVD assigns CVSS 6.5 with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H. GHSA assigns 5.9 with CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H. The difference is UI:N (NVD) versus UI:R (GHSA). NVD's assessment that no user interaction is required for DNS rebinding exploitation is the more conservative and defensively appropriate score. This publication uses the NVD score (6.5 MEDIUM) (NVD, GHSA-q5fh-2hc8-f6rq).

Affected Products

Am I Affected?

• Check whether Ray is deployed in your environment
• Verify the installed version: pip show ray — any version 2.53.0 or below is vulnerable (GHSA-q5fh-2hc8-f6rq)
• Determine whether the dashboard is network-accessible: check for --dashboard-host=0.0.0.0 in Ray launch configuration
• Review whether dashboard token authentication is enabled (it is disabled by default) (GHSA-q5fh-2hc8-f6rq)

Reading Guide

Abstract

CVE-2026-27482 is a medium-severity authentication bypass in the Ray AI compute framework's dashboard HTTP server. The server's middleware applies a blocklist to prevent browser-origin requests from issuing POST and PUT operations, but the DELETE method is absent from this blocklist. Three API endpoints — the Serve shutdown path, the job deletion path, and the job-agent deletion path — are therefore accessible without any authentication token on Ray versions 2.53.0 and below (GHSA-q5fh-2hc8-f6rq). Because dashboard token authentication is optional and disabled by default, and because operators commonly bind the dashboard to 0.0.0.0 for remote visibility, an attacker with same-network access or the ability to execute a DNS rebinding attack can reach these endpoints and cause availability disruption without credentials (GHSA-q5fh-2hc8-f6rq, NVD). The fix in Ray 2.54.0 replaces the blocklist approach with an allowlist that permits only GET, HEAD, and OPTIONS from browser-origin requests, closing the gap for all unsafe HTTP methods (GitHub PR #60526).

Key Findings

1. DELETE method omitted from browser-origin blocklist — Ray's dashboard middleware blocks POST and PUT from browser origins but does not block DELETE requests. Three API endpoints (DELETE /api/serve/applications/, DELETE /api/jobs/{id}, DELETE /api/job_agent/jobs/{id}) are therefore accessible without authentication (GHSA-q5fh-2hc8-f6rq).

2. Default-insecure configuration (RAXE assessment) — Dashboard token authentication is optional and disabled by default (GHSA-q5fh-2hc8-f6rq). Combined with the common practice of binding the dashboard to 0.0.0.0 for remote access (GHSA-q5fh-2hc8-f6rq), this creates a wide default attack surface.

3. DNS rebinding as remote exploitation vector — Even dashboards bound to internal interfaces are reachable if an internal user visits a malicious webpage that performs DNS rebinding. The attacker's JavaScript can issue DELETE requests against the dashboard through the victim's browser (GHSA-q5fh-2hc8-f6rq).

4. Availability-only impact — The vulnerability does not expose data or enable code execution. Impact is confined to terminating running jobs and shutting down Serve applications. However, in-progress computation (e.g., training state not checkpointed) is permanently lost (NVD).

5. Patch adopts allowlist over blocklist — The fix replaces the fragile blocklist (which required enumerating every dangerous method) with an allowlist (GET, HEAD, OPTIONS only), which fails safely when new methods are overlooked or added (GitHub PR #60526).

Attack Flow

+--------------------+
|  1. NETWORK        |  Attacker identifies network-accessible Ray dashboard
|  RECONNAISSANCE    |  (port 8265, bound to 0.0.0.0)
+--------+-----------+  (GHSA-q5fh-2hc8-f6rq)
         |
         v
+--------------------+
|  2. ACCESS PATH    |  Path A: Same-network direct access
|  SELECTION         |  Path B: DNS rebinding via malicious webpage
|                    |  (CVSS AC:H reflects these prerequisites)
+--------+-----------+  (NVD)
         |
         v
+--------------------+
|  3. DNS REBINDING  |  (path B only)
|  SETUP             |  Attacker domain with short TTL --> victim browses
|                    |  --> DNS re-resolves to dashboard internal IP
+--------+-----------+  (GHSA-q5fh-2hc8-f6rq)
         |
         v
+--------------------+
|  4. DELETE         |  DELETE /api/serve/applications/
|  REQUEST           |  DELETE /api/jobs/{submission_id}
|                    |  DELETE /api/job_agent/jobs/{submission_id}
|  No auth header    |  No token required (auth disabled by default)
+--------+-----------+  (GHSA-q5fh-2hc8-f6rq)
         |
         v
+--------------------+
|  5. MIDDLEWARE     |  Blocklist checks POST and PUT only
|  BYPASS            |  DELETE is not in the blocklist
|                    |  Request passes to handler unblocked
+--------+-----------+  (GHSA-q5fh-2hc8-f6rq)
         |
         v
+--------------------+
|  6. IMPACT         |  Running jobs terminated (STOPPED/FAILED)
|  AVAILABILITY      |  Serve applications shut down
|  DISRUPTION        |  In-progress computation lost
|                    |  No data exposure; no code execution
+--------------------+  (NVD)

Technical Details

Vulnerability Mechanics

Ray's dashboard HTTP server implements a middleware function designed to block browser-origin requests that could mutate server state. This middleware was designed to prevent cross-site request forgery (CSRF) style attacks by rejecting requests with browser-origin characteristics (such as a browser User-Agent or an Origin header) for state-changing HTTP methods (GHSA-q5fh-2hc8-f6rq).

However, the implementation used a blocklist approach that only enumerated POST and PUT as blocked methods. The DELETE method — which is equally capable of mutating state — was omitted from this list. As a result, three DELETE endpoints remained accessible to browser-origin requests without any authentication check (GHSA-q5fh-2hc8-f6rq):

• DELETE /api/serve/applications/ — triggers shutdown of all Ray Serve deployments
• DELETE /api/jobs/{job_or_submission_id} — terminates a submitted job
• DELETE /api/job_agent/jobs/{job_or_submission_id} — agent-level job deletion

Authentication Configuration

Dashboard token authentication in Ray is optional and disabled by default (GHSA-q5fh-2hc8-f6rq). When token authentication is disabled, no Authorization header is required for any dashboard API request. The combination of missing method protection and absent authentication means the three DELETE endpoints are fully unprotected on default-configured Ray deployments.

Attack Complexity and Prerequisites

The CVSS vector assigns Attack Complexity: High (AC:H), reflecting that exploitation requires either same-network access or DNS rebinding rather than direct internet exposure (NVD). Specifically:

1. Same-network access — An attacker on the same network segment as the Ray cluster can directly issue HTTP DELETE requests to port 8265.
2. DNS rebinding — An attacker can register a domain with a short TTL, serve a malicious webpage, and manipulate DNS resolution so that the victim's browser re-resolves the attacker's domain to the dashboard's internal IP address. The browser's same-origin policy does not prevent this because the hostname remains unchanged. JavaScript on the attacker's page then issues DELETE requests that the Ray server processes (GHSA-q5fh-2hc8-f6rq).

No authentication is required (PR:N) and no user interaction is needed for direct network exploitation (UI:N per NVD). The GHSA scoring differs on user interaction (UI:R), likely reflecting that the DNS rebinding path requires a user to visit a malicious page (GHSA-q5fh-2hc8-f6rq).

Impact Analysis

Per the NVD CVSS vector (NVD):

• Confidentiality: None — The vulnerability does not expose any data.
• Integrity: Low — Attackers can delete jobs but cannot modify data or inject code.
• Availability: High — Running jobs can be terminated and Serve applications shut down entirely, disrupting AI inference and training workloads.
• Scope: Unchanged — Impact is confined to the Ray dashboard component.

Weakness Classification

• CWE-306: Missing Authentication for Critical Function (GHSA-q5fh-2hc8-f6rq)
• CWE-396: Declaration of Catch for Generic Exception (NVD)

Patch Analysis

The fix was implemented in PR #60526 (merged 2026-01-27, commit 0fda8b824cdc9dc6edd763bb28dfd7d1cc9b02a4) and released in Ray 2.54.0 (GitHub PR #60526).

The patch replaces the blocklist strategy with an allowlist mechanism. A new get_browser_safe_methods_middleware function permits exclusively GET, HEAD, and OPTIONS methods from browser-origin requests. All other HTTP methods — including DELETE, POST, PUT, and PATCH — are rejected at the middleware layer before reaching any endpoint handler (GitHub PR #60526).

This allowlist approach is the correct defence pattern. Blocklists are fragile because they require the developer to enumerate every dangerous method and update the list when new methods are introduced. Allowlists fail safely by default: any method not explicitly permitted is automatically rejected, preventing the class of omission error that caused this vulnerability (RAXE assessment).

Confidence & Validation

Assessment Confidence: High

Detection Signatures (Formal Rules)

Sigma Rule 1 — HTTP DELETE Request to Ray Dashboard API Endpoint

Detects unauthenticated HTTP DELETE requests to the three Ray dashboard API endpoints disclosed in CVE-2026-27482 (GHSA-q5fh-2hc8-f6rq).

title: Ray Dashboard Unauthenticated DELETE Request to API Endpoint
id: ray-dashboard-delete-cve-2026-27482
status: experimental
description: >
  Detects HTTP DELETE requests to Ray dashboard API endpoints that are unprotected
  on Ray <= 2.53.0, as documented in CVE-2026-27482 and GHSA-q5fh-2hc8-f6rq.
  The three affected paths are /api/serve/applications/, /api/jobs/{id}, and
  /api/job_agent/jobs/{id}. On unpatched deployments these endpoints require no
  authentication token and will return HTTP 2xx, resulting in job deletion or
  Serve shutdown.
author: RAXE Labs (M. Hirani)
date: 2026/03/09
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27482
  - https://github.com/advisories/GHSA-q5fh-2hc8-f6rq
  - https://github.com/ray-project/ray/pull/60526
tags:
  - attack.impact
  - attack.t1489
  - cve.2026-27482
logsource:
  category: webserver
  product: ray_dashboard
detection:
  selection_method:
    cs-method: 'DELETE'
  selection_paths:
    cs-uri-stem|contains:
      - '/api/serve/applications/'
      - '/api/jobs/'
      - '/api/job_agent/jobs/'
  selection_port:
    dst_port: 8265
  filter_no_auth:
    cs-Authorization: '*'
  condition: selection_method and selection_paths and selection_port and not filter_no_auth
falsepositives:
  - Authorised administrative scripts that issue DELETE via the Ray Python SDK may
    not pass an Authorization header if running on the cluster head node and using
    direct HTTP; review the source IP against the known cluster node inventory.
  - Automated testing pipelines with direct HTTP access to the dashboard.
level: high

Sigma Rule 2 — Ray Dashboard DELETE with Browser User-Agent (DNS Rebinding Indicator)

Detects DELETE requests arriving at the Ray dashboard with a browser-style User-Agent, which is anomalous in legitimate operation and indicates a DNS rebinding attack (GHSA-q5fh-2hc8-f6rq).

title: Ray Dashboard DELETE Request with Browser User-Agent (DNS Rebinding Indicator)
id: ray-dashboard-dns-rebinding-delete-cve-2026-27482
status: experimental
description: >
  Detects an HTTP DELETE request to the Ray dashboard (default port 8265) that carries
  a browser-style User-Agent header. In a DNS rebinding attack against CVE-2026-27482,
  the victim's browser issues the DELETE; the resulting log entry will contain a
  browser User-Agent rather than a Python requests or curl agent. This combination —
  DELETE method, Ray dashboard path, browser User-Agent — is highly anomalous in
  legitimate operation.
author: RAXE Labs (M. Hirani)
date: 2026/03/09
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27482
  - https://github.com/advisories/GHSA-q5fh-2hc8-f6rq
tags:
  - attack.impact
  - attack.t1489
  - cve.2026-27482
logsource:
  category: webserver
  product: ray_dashboard
detection:
  selection_method:
    cs-method: 'DELETE'
  selection_paths:
    cs-uri-stem|contains:
      - '/api/serve/applications/'
      - '/api/jobs/'
      - '/api/job_agent/jobs/'
  selection_browser_agent:
    cs-User-Agent|contains:
      - 'Mozilla/'
      - 'Chrome/'
      - 'Safari/'
      - 'Firefox/'
      - 'Gecko/'
  condition: selection_method and selection_paths and selection_browser_agent
falsepositives:
  - Browser-based tooling (e.g., a developer using the browser DevTools Network tab
    to manually issue a DELETE) is possible but highly unusual in production.
level: high

Sigma Rule 3 — DNS Rebinding Precondition: Short-TTL Resolution to RFC-1918 Address

Detects the network-layer precursor to a DNS rebinding attack, where an external hostname resolves to a private (RFC-1918) address with a very short TTL (GHSA-q5fh-2hc8-f6rq).

title: DNS Rebinding Precondition — Short TTL Resolving to RFC-1918 Address
id: ray-dashboard-dns-rebinding-prereq-cve-2026-27482
status: experimental
description: >
  Detects a DNS A-record response for an external hostname that resolves to an
  RFC-1918 private address with a very short TTL (<=30 seconds). This pattern is
  the necessary precondition for a DNS rebinding attack against internal services
  such as the Ray dashboard (CVE-2026-27482). The rule is not Ray-specific; it
  covers the network-layer precursor that enables browser-based exploitation of
  any internal HTTP service exposed without authentication.
author: RAXE Labs (M. Hirani)
date: 2026/03/09
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27482
  - https://github.com/advisories/GHSA-q5fh-2hc8-f6rq
tags:
  - attack.impact
  - attack.t1557
  - cve.2026-27482
logsource:
  category: dns
detection:
  selection_rfc1918_answer:
    dns.answers.data|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  selection_short_ttl:
    dns.answers.ttl|lte: 30
  filter_legitimate_split_horizon:
    dns.question.name|endswith:
      - '.internal'
      - '.corp'
      - '.local'
  condition: selection_rfc1918_answer and selection_short_ttl and not filter_legitimate_split_horizon
falsepositives:
  - Legitimate split-horizon DNS deployments where an external domain name
    resolves to internal IPs intentionally (e.g., AWS Route 53 private hosted
    zones with short TTLs). Tune the filter_legitimate_split_horizon list to
    exclude known internal domains.
  - CDN providers that use very short TTLs for health-based routing may
    occasionally resolve to RFC-1918 ranges in misconfigured environments.
level: medium

Sigma Rule 4 — Ray Process Log: Unexpected Serve Shutdown or Abrupt Job Termination

Detects Ray application log entries indicating that a Serve application was shut down or a job was deleted without a corresponding authorised CLI invocation (GHSA-q5fh-2hc8-f6rq).

title: Ray Serve Unexpected Shutdown or Job Deleted via Dashboard API
id: ray-dashboard-serve-shutdown-cve-2026-27482
status: experimental
description: >
  Detects log messages in the Ray dashboard or supervisor logs indicating that a
  Serve application was shut down or a job was deleted without a corresponding
  authorised CLI or SDK event on the cluster head node. On Ray <= 2.53.0
  (CVE-2026-27482), these actions can be triggered by an unauthenticated HTTP
  DELETE request, making unexpected occurrences of these log entries an indicator
  of exploitation.
author: RAXE Labs (M. Hirani)
date: 2026/03/09
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27482
  - https://github.com/advisories/GHSA-q5fh-2hc8-f6rq
tags:
  - attack.impact
  - attack.t1489
  - cve.2026-27482
logsource:
  product: ray
  category: application
detection:
  selection_serve_shutdown:
    log.message|contains:
      - 'Deleting all serve applications'
      - 'Shutting down Serve'
      - 'serve shutdown'
  selection_job_deleted:
    log.message|contains:
      - 'Deleting job'
      - 'Job deleted'
      - 'Stopping job'
  selection_state_transition:
    log.message|contains:
      - '"status": "STOPPED"'
      - '"status": "FAILED"'
  condition: selection_serve_shutdown or (selection_job_deleted and selection_state_transition)
falsepositives:
  - Authorised job cancellation via the Ray CLI (ray job stop) will produce
    identical log messages; correlate with a corresponding CLI invocation event
    on the head node (shell history, auditd execve) to distinguish authorised
    from unauthorised activity.
  - Automated pipeline teardown scripts that programmatically delete jobs at
    the end of a workflow.
level: medium

Detection & Mitigation

Immediate Actions

1. Upgrade to Ray 2.54.0 — This is the primary remediation. The patch replaces the browser-origin method blocklist with an allowlist (GET, HEAD, OPTIONS only), closing the DELETE gap and all future method-omission risks (GHSA-q5fh-2hc8-f6rq).

2. Enable dashboard token authentication — If upgrade is not immediately possible, enable token authentication on the Ray dashboard. This adds an Authorization header requirement that mitigates exploitation even on unpatched versions (GHSA-q5fh-2hc8-f6rq).

3. Restrict dashboard network exposure — Ensure the Ray dashboard is not bound to 0.0.0.0. Bind to localhost (127.0.0.1) or a management-only interface. Use firewall rules or security groups to restrict access to authorised administrators only.

Detection Guidance

• Web server log monitoring — Deploy Sigma Rules 1 and 2 against Ray dashboard access logs (default path: /tmp/ray/session_latest/logs/dashboard.log). Configure log forwarding via Filebeat or Fluentd to parse the access log into structured fields (cs-method, cs-uri-stem, cs-User-Agent, cs-Authorization).
• DNS monitoring — Deploy Sigma Rule 3 against DNS resolver logs to detect DNS rebinding preconditions. This rule is not Ray-specific and provides broader value against all DNS rebinding attacks.
• Application log correlation — Deploy Sigma Rule 4 against Ray application logs. Correlate job state transitions (STOPPED/FAILED) with authorised CLI invocations on the head node to distinguish legitimate teardown from exploitation.
• Version inventory — The most direct control is a package inventory check: pip show ray | grep Version against the vulnerability threshold of 2.53.0. Detection rules augment but do not replace patch verification.

Strategic Recommendations

• Establish Ray deployment configuration standards — Mandate authentication, restrict dashboard binding, and document baseline security configuration for all Ray clusters in the environment.
• Audit DNS rebinding exposure — The DNS rebinding attack path documented in this advisory applies to any internal web-based administration interface served without authentication. Conduct a broader assessment of internal HTTP services for DNS rebinding susceptibility (RAXE assessment).
• Monitor Ray security advisories — This is not the first authentication-related vulnerability in Ray's dashboard infrastructure. Establish a monitoring process for future Ray security advisories (RAXE assessment).

Indicators of Compromise

Strategic Context

The Ray dashboard authentication bypass fits within a broader pattern of default-insecure configurations in AI infrastructure tooling (RAXE assessment). Several observations make this finding strategically noteworthy:

AI compute infrastructure operates below the application security radar. Ray clusters are typically provisioned and managed by ML engineers rather than security teams. Default configurations are rarely reviewed against security baselines, and internal-facing dashboards are commonly assumed to be safe from exploitation. This advisory demonstrates that network-adjacent attackers — or remote attackers via DNS rebinding — can disrupt AI workloads without any credentials.

Blocklist-to-allowlist transitions signal maturing security posture. The patch's shift from a method blocklist to a method allowlist is a well-understood defensive improvement in software security. The fact that this transition was prompted by a CVE rather than proactive security review suggests that Ray's dashboard security model is still maturing. Organisations should expect further refinements — and potentially further advisories — as additional edge cases are discovered (RAXE assessment).

DNS rebinding remains an underappreciated attack vector. While DNS rebinding is a well-known technique in the security research community, it is infrequently covered in operational security training and rarely tested during penetration assessments of internal tooling. The explicit identification of DNS rebinding as an exploitation path for this vulnerability highlights the ongoing relevance of this attack technique against any internal HTTP service that does not validate the Host header or enforce authentication (GHSA-q5fh-2hc8-f6rq).

Availability disruption in AI systems has outsized operational impact. Unlike traditional web application availability disruption (where requests can typically be replayed), terminating a long-running AI training job may result in hours or days of lost computation if the workload is not configured with checkpointing. Organisations should treat availability vulnerabilities in AI compute infrastructure with higher urgency than equivalent web application vulnerabilities (RAXE assessment).

References

1. CVE-2026-27482 — NVD entry, CVSS 6.5 MEDIUM (NVD)
2. GHSA-q5fh-2hc8-f6rq — GitHub Security Advisory, vendor-confirmed (GHSA-q5fh-2hc8-f6rq)
3. ray-project/ray#60526 — Fix PR introducing get_browser_safe_methods_middleware, merged 2026-01-27 (GitHub PR #60526)
4. Fix commit 0fda8b8 — Patch commit (GitHub)
5. FIRST EPSS — Exploit Prediction Scoring System data for CVE-2026-27482