CVE-2026-57516: Ray: RCE via pickle/torch deserialization in WebDataset
GHSA-hhrp-gw25-jr43 HIGH CISA: ATTENDRay's WebDataset reader blindly deserializes tar archive contents with pickle.loads() and torch.load(weights_only=False), so any tar file fed into read_webdataset() can execute arbitrary code on every Ray worker that processes it — a classic pickle/PyTorch RCE pattern (CWE-502) landing in a distributed compute framework rather than a single host. Ray underpins training and data-preprocessing pipelines at scale, so one malicious dataset shard pulled from a shared bucket, a public dataset mirror, or an untrusted collaborator can pivot into code execution across an entire worker fleet, not just one machine. There's no CISA KEV listing, no public exploit, and no EPSS score yet, so this hasn't been weaponized in the wild, but the trigger condition — pointing read_webdataset() at a crafted tar, no auth or elevated privileges needed — is a routine action in ML data-loading workflows. Upgrade to Ray 2.56.0 immediately, and until every worker is patched, treat WebDataset inputs as untrusted: restrict read_webdataset() to vetted internal sources and monitor Ray worker processes for unexpected pickle/torch.load activity or outbound connections.
What is the risk?
CVSS 8.8 (network, low complexity, no privileges, high confidentiality/integrity/availability impact) reflects a severe technical vulnerability, tempered only by the required user interaction (a pipeline must actually load the malicious archive). In practice that bar is low: dataset ingestion is a routine, often automated step in ML pipelines, and WebDataset-format tar shards are commonly sourced from shared storage, third-party mirrors, or collaborators outside the security team's direct control. No active exploitation or public PoC exists today, but the vulnerability class (unsafe pickle/torch.load deserialization) is extremely well understood by attackers and trivially weaponizable once a target's ingestion path is known. Organizations running Ray clusters for training or large-scale data processing that ingest WebDataset shards from anything less than a fully trusted, access-controlled source face material exposure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Ray | pip | < 2.56.0 | 2.56.0 |
Do you use Ray? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to Ray >= 2.56.0, which removes the unconditional pickle.loads()/torch.load(weights_only=False) calls in webdataset_datasource.py. Until patched, do not call read_webdataset() on tar archives from external, shared, or otherwise untrusted sources — restrict ingestion to vetted internal buckets with strict access control. Scan .pkl/.pickle members with a tool like picklescan before ingestion, and avoid torch.load() on .pt/.pth files without weights_only=True. Harden worker isolation (no cloud metadata endpoint access, restricted egress, minimal IAM scope) so a single-worker compromise doesn't cascade into cluster-wide or cloud-wide compromise. Monitor Ray worker processes for anomalous pickle/torch.load invocations, unexpected subprocess spawns, or outbound network connections correlated with dataset ingestion jobs.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-57516?
Ray's WebDataset reader blindly deserializes tar archive contents with pickle.loads() and torch.load(weights_only=False), so any tar file fed into read_webdataset() can execute arbitrary code on every Ray worker that processes it — a classic pickle/PyTorch RCE pattern (CWE-502) landing in a distributed compute framework rather than a single host. Ray underpins training and data-preprocessing pipelines at scale, so one malicious dataset shard pulled from a shared bucket, a public dataset mirror, or an untrusted collaborator can pivot into code execution across an entire worker fleet, not just one machine. There's no CISA KEV listing, no public exploit, and no EPSS score yet, so this hasn't been weaponized in the wild, but the trigger condition — pointing read_webdataset() at a crafted tar, no auth or elevated privileges needed — is a routine action in ML data-loading workflows. Upgrade to Ray 2.56.0 immediately, and until every worker is patched, treat WebDataset inputs as untrusted: restrict read_webdataset() to vetted internal sources and monitor Ray worker processes for unexpected pickle/torch.load activity or outbound connections.
Is CVE-2026-57516 actively exploited?
No confirmed active exploitation of CVE-2026-57516 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-57516?
Upgrade to Ray >= 2.56.0, which removes the unconditional pickle.loads()/torch.load(weights_only=False) calls in webdataset_datasource.py. Until patched, do not call read_webdataset() on tar archives from external, shared, or otherwise untrusted sources — restrict ingestion to vetted internal buckets with strict access control. Scan .pkl/.pickle members with a tool like picklescan before ingestion, and avoid torch.load() on .pt/.pth files without weights_only=True. Harden worker isolation (no cloud metadata endpoint access, restricted egress, minimal IAM scope) so a single-worker compromise doesn't cascade into cluster-wide or cloud-wide compromise. Monitor Ray worker processes for anomalous pickle/torch.load invocations, unexpected subprocess spawns, or outbound network connections correlated with dataset ingestion jobs.
What systems are affected by CVE-2026-57516?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, data preprocessing pipelines, distributed compute clusters.
What is the CVSS score for CVE-2026-57516?
CVE-2026-57516 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.55%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.002 Data AML.T0011 User Execution AML.T0011.000 Unsafe AI Artifacts AML.T0018.002 Embed Malware Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker uploads a poisoned WebDataset shard (e.g., a plausibly-named 'training_shard_0042.tar') to a public dataset repository or a bucket shared with the target organization. Inside the tar, one entry is a .pkl file with a malicious __reduce__ payload, or a .pth file crafted to execute code when loaded with torch.load(weights_only=False). When the victim's Ray Data/Train pipeline calls read_webdataset() to load the shard for a training or preprocessing job, _default_decoder() automatically deserializes every matching entry with no validation — executing the payload on every worker node assigned to process that shard, potentially dozens of nodes in a distributed job simultaneously. This gives the attacker a foothold across the cluster and access to any cloud credentials attached to the compromised workers.
Weaknesses (CWE)
CWE-502 Deserialization of Untrusted Data
Primary
CWE-502 Deserialization of Untrusted Data
Primary
CWE-94 Improper Control of Generation of Code ('Code Injection')
Primary
CWE-502 Deserialization of Untrusted Data CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
- [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H References
- github.com/ray-project/ray/pull/63469
- github.com/ray-project/ray/pull/63470
- github.com/ray-project/ray/releases/tag/ray-2.56.0
- github.com/ray-project/ray/security/advisories/GHSA-hhrp-gw25-jr43
- vulncheck.com/advisories/ray-unsafe-deserialization-rce-via-webdataset-reader
- github.com/advisories/GHSA-hhrp-gw25-jr43
- github.com/pypa/advisory-database/tree/main/vulns/ray/PYSEC-2026-2273.yaml
- github.com/ray-project/ray/commit/41443a18f9e6403a072de69098a279c23e2d943c
- nvd.nist.gov/vuln/detail/CVE-2026-57516
Timeline
Related Vulnerabilities
CVE-2023-6019 9.8 Ray: unauthenticated RCE via dashboard command injection
Same package: ray CVE-2023-48022 9.8 Ray: unauthenticated RCE via job submission API
Same package: ray CVE-2023-6021 9.3 Ray: LFI allows unauthenticated file read
Same package: ray CVE-2023-6020 9.3 Ray: unauthenticated LFI exposes entire filesystem
Same package: ray CVE-2026-50158 7.7 yutu: arbitrary file write via MCP caption-download tool
Same package: ray