CVE-2026-57516: 
Chainguard vulnerability analysis and mitigation

CVE-2026-57516 is an unsafe deserialization vulnerability in Anyscale Ray's WebDataset reader that enables remote code execution (RCE) via a malicious TAR archive. 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 archive. All Ray versions prior to 2.56.0 are affected. The vulnerability was published on July 1, 2026, with a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory).

The root cause is deserialization of untrusted data (CWE-502) and improper code injection (CWE-94) in python/ray/data/_internal/datasource/webdataset_datasource.py (lines 175–225). The _default_decoder() function routes TAR entry file extensions to decoders without any validation: .pkl/.pickle entries are passed directly to pickle.loads(value), and .pt/.pth entries are passed to torch.load(io.BytesIO(value), weights_only=False) — explicitly overriding PyTorch 2.6's safer default of weights_only=True. The decoder fires by default for every ray.data.read_webdataset() call (default decoder=True), requiring no flags or opt-in from the user. An attacker only needs to supply a malicious TAR archive via any path accepted by read_webdataset(), including S3 URLs, HTTP URLs, HuggingFace Hub dataset shards, or local files. This vulnerability is a sibling of GHSA-mw35-8rx3-xf9r (Parquet Arrow Extension Type deserialization, patched in Ray 2.55.0) but in a different, previously unaddressed code path (GitHub Advisory, PR #63469).

Successful exploitation grants an attacker arbitrary code execution as the Ray remote worker process on every worker node that processes the malicious archive, resulting in full confidentiality, integrity, and availability compromise of affected workers. Because Ray workers operate in distributed clusters, a single malicious TAR file can propagate RCE across all worker nodes that consume it, enabling lateral movement within the Ray cluster. Sensitive data accessible to the worker process — including model weights, training data, credentials in environment variables, and cloud provider metadata — is at risk of exfiltration (GitHub Advisory).

A complete, runnable proof-of-concept (PoC) Python script is publicly available in the GitHub Security Advisory, demonstrating end-to-end RCE by crafting a malicious TAR file and calling ray.data.read_webdataset(). The PoC was confirmed on Ray 2.55.1 and writes a filesystem marker file as evidence of code execution. The EPSS score is 0.00483 (low probability of near-term exploitation), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the advisory date. No threat actor attribution has been reported (GitHub Advisory).

1. Craft a malicious TAR archive: Create a Python pickle payload using a class with a __reduce__ method that executes an arbitrary shell command (e.g., writing a marker file, spawning a reverse shell). Serialize it with pickle.dumps() and package it as a TAR entry named 000000.pkl (or 000000.pt for the PyTorch variant using torch.save()).
2. Host or deliver the archive: Place the malicious TAR at a location accessible to the target Ray cluster — e.g., an S3 bucket, an HTTP server, a HuggingFace Hub dataset, or a shared filesystem path.
3. Trigger the vulnerable API: Induce the victim to call ray.data.read_webdataset(paths=["s3://bucket/poisoned.tar"]) (or any equivalent path). This can occur through supply-chain compromise of a shared dataset, a model-zoo tarball, or social engineering.
4. Achieve RCE on Ray workers: When .take_all(), .iter_batches(), or any consuming operation is called, _default_decoder() fires on every worker that processes the archive, invoking pickle.loads() on the .pkl entry and executing the attacker's payload as the Ray worker process user.
5. Lateral movement: With code execution on one or more Ray workers, the attacker can access cluster resources, exfiltrate data, pivot to other nodes, or establish persistence (GitHub Advisory).

• File System: Unexpected files created by the Ray worker process (e.g., marker files in /tmp/ such as /tmp/ray_webdataset_poc_rce_marker); new scripts, cron jobs, or SSH keys written by the worker user account.
• Process: Unusual child processes spawned by Ray worker Python processes, such as /bin/sh, /bin/bash, curl, wget, python, or nc; processes running as the Ray worker user that are not part of normal Ray operations.
• Network: Unexpected outbound connections from Ray worker nodes to external IPs or domains, particularly shortly after read_webdataset() calls; connections to attacker-controlled infrastructure for reverse shells or data exfiltration.
• Logs: Ray worker logs showing errors or unusual output during read_webdataset() or .take_all() / .iter_batches() calls; OS-level audit logs (e.g., auditd) recording execve syscalls from the Ray worker process spawning shell commands (GitHub Advisory).

Primary remediation: Upgrade Ray to version 2.56.0 or later, which gates the unsafe .pkl/.pickle and .pt/.pth deserialization branches in _default_decoder() behind the RAY_DATA_WEBDATASET_ALLOW_UNSAFE_DESERIALIZATION=1 environment variable (Ray 2.56.0 Release, PR #63469).

Workarounds (if immediate upgrade is not possible):

• Pass decoder=None or a custom safe decoder callable to ray.data.read_webdataset() to bypass _default_decoder() entirely.
• Restrict access to the read_webdataset() API and validate all TAR archives against a trusted allowlist before processing.
• Implement network segmentation to limit the blast radius of any compromised Ray workers.
• Do not set RAY_DATA_WEBDATASET_ALLOW_UNSAFE_DESERIALIZATION=1 unless processing TAR archives from fully trusted sources.

The vulnerability was reported by security researchers SSJCorpSec, thesecguy45, and sfwani, and remediated by Ray maintainer bveeramani (GitHub Advisory). The advisory explicitly notes this is a sibling of GHSA-mw35-8rx3-xf9r (patched in Ray 2.55.0), highlighting a pattern of unsafe deserialization in Ray Data's standard data-loading APIs. A Bluesky post from cyberhub.blog referenced the vulnerability shortly after disclosure, indicating some community awareness, though no major media coverage or significant public debate has been observed.