Ray AI Framework Flaw CVE-2026-57516: Loading a Malicious Dataset Triggers Server Takeover — Update to 2.56.0
Ray, the AI distributed-computing framework used by OpenAI and Uber, has a flaw (CVE-2026-57516): loading a crafted dataset (.tar) runs arbitrary code on the server. Ingesting public data and models becomes dangerous. Severity 8.8 — update to 2.56.0.
Table of contents
Ray, the AI distributed-computing framework used by OpenAI and Uber, has a flaw (CVE-2026-57516): loading a crafted dataset (.tar) runs arbitrary code on the server. Ingesting public data and models becomes dangerous. Severity 8.8 — update to 2.56.0.
A vulnerability that lets an attacker take over a server just by loading a crafted dataset has been found in "Ray," the distributed-computing framework behind large-scale AI and machine-learning workloads. It is tracked as CVE-2026-57516, with a severity of 8.8 out of 10 ("High").
Ray is known for having been used by OpenAI to train ChatGPT, and it is adopted in the AI platforms of many companies including Uber, Spotify, and Netflix. This flaw is in Ray's data-loading function read_webdataset(): the moment an attacker-supplied malicious data file (in .tar format) is ingested, arbitrary code runs on the server. It turns the everyday act of pulling in public datasets and model distributions into a danger. The developer has released a fixed version, "2.56.0," so anyone on an earlier version needs to update right away.
| Item | Details |
|---|---|
| Tracking ID | CVE-2026-57516 |
| Affected software | Ray (AI distributed-computing framework) |
| Affected versions | Before 2.56.0 |
| Fixed version | 2.56.0 |
| Severity | CVSS 8.8 / 10 ("High") |
| Type | Unsafe deserialization (CWE-502 / CWE-94) |
| Precondition | Loading a malicious dataset (unauthenticated) |
| Exploitation | None reported so far (not in CISA KEV) |
| Ray's scale | 40,000+ GitHub stars 10M+ weekly downloads |
Who would exploit this, and why
The target is development teams that pull AI training data and models from public repositories or shared storage. An attacker places a malicious file disguised as a legitimate dataset somewhere anyone can fetch it: cloud storage (S3) left writable by a misconfiguration, data repositories served over the web, or distributions on model- and data-sharing sites.
When a developer loads that malicious dataset with Ray, a program embedded in the data runs automatically just from being loaded, and the development server or training environment is taken over. What makes it nasty is that it fires at the ingestion stage — before you even try to use the contents.
Once taken over, the damage does not stop at that one machine. An AI training environment concentrates training data, models under development, and connection details (credentials) to clouds and databases. From that foothold, an attacker could steal data and models, tamper with models, and move deeper into the internal network. It is also a form of "supply-chain attack," in which poisoned data or models circulate as distributions, so the trustworthiness of what you ingest is on the line. That is why the update and operational review below are needed.
What kind of tool is Ray?
Ray is an open-source platform that lets programs written in Python and AI workloads scale easily from a single computer out to many servers. Born at UC Berkeley and now developed largely by Anyscale, it distributes data-heavy AI training and production model serving across multiple servers to run them efficiently.
Usage is very broad: it has over 40,000 stars on GitHub and more than 10 million weekly downloads. OpenAI is said to have used Ray to coordinate the training of ChatGPT, and it is used in the AI platforms of well-known companies such as Uber, Spotify, Netflix, and ByteDance. In short, it is one of the foundations of modern AI development.
This flaw is in Ray's data-loading part (Ray Data). In AI training, a format called "WebDataset" — which bundles large numbers of images, audio, and so on (internally a .tar archive) — is commonly used, and Ray provides a dedicated function to read it. That reading process had a dangerous hole.
What actually happens: inside the flaw
The cause is that the "restore step" when loading data trusts the contents too much. In programming, to store and transmit data it is common to pack it into a fixed form and then turn it back into a usable form (deserialization). If you pass crafted data to that restore step, arbitrary code can run — and Python's "pickle" mechanism is especially known for this danger.
According to the developer's advisory, Ray's read_webdataset(), in its default reader, restored contents without validation based on the file extension. Specifically, .pickle/.pkl files are restored with pickle as-is, and .pt/.pth files are read with torch.load() (with its safety check disabled). If either is crafted, the attacker's program runs at that moment.
What makes it nasty is that this restore fires before you begin using the data in earnest. It runs from ordinary operations that simply pull the data through, such as .take_all() or .iter_batches(). The developer lists delivery paths for a malicious .tar: an S3 bucket made writable by misconfiguration, web-served WebDataset repositories, dataset mirrors on the Hugging Face Hub, and model-zoo tarballs commonly used in computer vision. All are places AI developers touch daily. For why pickle-format files are dangerous, see our article on the flaws in "picklescan," a tool that inspects AI models for dangerous code.
How dangerous is it, really? Read the preconditions correctly
The severity is CVSS 8.8, classed as "High." A successful takeover is about as bad as it gets, but let us pin down the conditions precisely.
This flaw cannot be triggered unilaterally by anyone over the network. The severity breakdown notes "user interaction required," meaning it presupposes that the user loads an attacker-supplied malicious dataset with Ray. Conversely, an operation that only ever loads trusted, in-house data is less likely to be affected on this path.
Still, "I load it myself, so it's safe" does not hold. In AI development, pulling in public datasets and models made by others is entirely routine. A distribution source you believed trustworthy could have been compromised, or a fake could have slipped into a mirror. The basic stance against this class of threat is to treat data and models brought in from outside as "programs that may execute."
Is my environment at risk? A version-by-version guide
First, check your version with pip show ray. The table below helps you judge your situation.
| Your version | Loads external datasets | In-house data only |
|---|---|---|
| Before 2.56.0 | High update now | Medium still recommended |
| 2.56.0 or later | Patched | Patched |
| Ray not used | Not affected | Not affected |
If you only handle trusted in-house data, the urgency is lower, but operations where data received from a team or outside gets mixed in are not unusual. Either way, updating to 2.56.0 or later is recommended.
An engineer's view: Ray keeps repeating the same hole in data loading
This CVE-2026-57516 is not a one-off accident. In Ray's data-loading part (Ray Data), a flaw that restores externally received data by unsafe means was found not long ago as well.
| Tracking ID | Trigger | Fixed in |
|---|---|---|
| CVE-2026-41486 | Reading Parquet files (cloudpickle) | 2.55.0 |
| CVE-2026-57516 | Reading WebDataset (pickle / torch.load) | 2.56.0 |
The immediately preceding CVE-2026-41486 was a flaw where, when reading the different Parquet format, contents were restored as-is with cloudpickle. The format differs, but both spring from the same root: restoring data that came from outside in a form that can execute. To an engineer's eye, this reflects less a Ray-specific problem than the continued use of "convenient but dangerous restore mechanisms" like pickle and torch.load across each data-loading path. Fixing one loading path tends to leave the same danger in a path for another format, so flaws of the same family keep recurring.
The practical lesson is clear: limit the data and models you ingest from outside to trusted sources, and where possible switch to safe loading methods (formats that do not use pickle, or loading with safety checks enabled). On the same kind of AI platform, the feature store Feast also had a takeover via an unsafe restore step, and this "danger of the restore step" is a weakness shared across AI development tools. Inspecting the components and data you bring in is worth revisiting alongside the ideas in our OSS supply-chain scanner overview.
Has it been exploited?
As of now, there are no confirmed reports of this vulnerability being used in real attacks. CVE-2026-57516 is also not listed in the "Known Exploited Vulnerabilities (KEV)" catalog published by the U.S. cybersecurity agency CISA.
However, the vulnerability details and the fix are public. Distributing a poisoned dataset and waiting for a target to load it is a realistic supply-chain attack against AI development. "Not yet attacked" is not a reason to skip the update.
What to do now
The top priority is to update Ray to the fixed version 2.56.0 or later. Because it is distributed as a Python package, you can update it with something like pip install --upgrade ray. Check the latest version on the distribution page.
Beyond updating, it is safe to review your operations. First, limit the sources of the datasets and models you load to a trusted range. It is safest not to load, as-is, a .tar of unknown origin or a distribution containing pickle-format files (.pkl/.pt). Next, run training and data processing in an isolated environment with restricted network and file access, so that even if malicious code runs, the damage is contained. Running ingested models and data through a tool that inspects for embedded dangerous code is also effective.
Summary
CVE-2026-57516 is a vulnerability in the AI distributed-computing framework Ray where merely loading a malicious dataset (.tar) lets a program be hijacked on the server. The severity is a high CVSS 8.8; exploitation presupposes loading malicious data, but for AI development where ingesting public data and models is routine, it is a realistic threat. It affects versions before 2.56.0 and is fixed in the latest 2.56.0.
What you cannot overlook is that Ray has repeatedly shipped RCE via unsafe restoration across its data-loading paths. Rather than calling it done after this update, treat data and models ingested from outside as "things that may execute," and shift your operations toward limiting sources and running in isolated environments. Start by checking, right now, whether your environment's Ray is on 2.56.0 or later.
References

Makoto Horikawa
Backend Engineer / AWS / Django