Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ray.data.readwebdataset(paths=...) is a @PublicAPI(stability="alpha") reader for WebDataset-format TAR files. Its default decoder=True invokes defaultdecoder on every sample's keys, which routes file extension to a decoder by extension. Two of those branches deserialize attacker-controlled bytes with no validation: - .pickle / .pkl - pickle.loads(value) - .pt / .pth - torch.load(io.BytesIO(value), weightsonly=False) Both fire during a standard ray.data.readwebdataset(...).takeall() / .iterbatches() call. No flags, no opt-in, no environment variable. An attacker who can supply a TAR (via S3 share, HuggingFace Hub mirror, email attachment, model-zoo, or any HTTP URL the user passes to readwebdataset) achieves arbitrary code execution in the calling Ray process at schema-sample time, before row data is consumed. This is the same class of bug as GHSA-mw35-8rx3-xf9r (Parquet Arrow Extension Type cloudpickle deserialization, patched in 2.55.0): standard data-loading API,…
Recommended action: Upgrade to 2.56.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability was identified in Ray Dashboard (default port 8265) in Ray versions prior to 2.8.1. Due to improper validation and sanitization of user-supplied paths in the static file handling mechanism, an attacker can use traversal sequences (e.g., ../) to access files outside the intended static directory, resulting in local file disclosure.
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/httpserverhead.py#getbrowsersnopostputmiddleware only checks POST/PUT via isbrowserrequest (UA/Origin/Sec-Fetch heuristics). DELETE is not gated. - Endpoints lacking browser protection/auth by default: - python/ray/dashboard/modules/serve/servehead.py: @routes.delete("/api/serve/applications/") calls serve.shutdown(). - python/ray/dashboard/modules/job/jobhead.py: @routes.delete("/api/jobs/{joborsubmissionid}"). - python/ray/dashboard/modules/job/jobagent.py: @routes.delete("/api/jobagent/jobs/{joborsubmissionid}") (not wrapped with…
Recommended action: Upgrade to 2.54.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/jobagent/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…
Recommended action: Upgrade to 2.52.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.43.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LFI in Ray's /static/ directory allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection exists in Ray's cpuprofile URL parameter allowing attackers to execute os commands on the system running the ray dashboard remotely without authentication.
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LFI in Ray's log API endpoint allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.