PT-2026-42205 · Pypi · Diffusers

Published

2026-05-20

·

Updated

2026-05-26

·

CVE-2026-45804

CVSS v3.1

7.5

High

VectorAV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Background

This vulnerability is found in the diffusers package - the transformers-equivalent library for diffusion models.
It is found in the DiffusionPipeline.from pretrained flow, which is used to load a pipeline from the HuggingFace Hub.
This function has a trust remote code guard: if the repository’s model index.json references a custom pipeline class defined in a .py file in the repo, the load is blocked unless trust remote code=True is explicitly passed:
ValueError: The repository for attacker/repo contains custom code in pipeline.py
which must be executed to correctly load the model. You can inspect the repository
content at https://hf.co/attacker/repo/blob/main/pipeline.py.
Please pass the argument `trust remote code=True` to allow custom code to be run.
The vulnerability allows arbitrary code execution through the custom pipeline flow from a Hub repo, with no custom pipeline or trust remote code kwargs passed. The from pretrained call succeeds and returns a functional pipeline.

Naive Flow

DiffusionPipeline.from pretrained begins by popping all relevant arguments from kwargs into local variables, then calls DiffusionPipeline.download() to fetch the repo files:
# pipeline utils.py:853
cached folder = cls.download(
  pretrained model name or path,
  ...
  custom pipeline=custom pipeline,
  trust remote code=trust remote code,
  ...
)
Inside download(), model index.json is fetched first as a standalone file via hf hub download:
# pipeline utils.py:1636
config file = hf hub download(
  pretrained model name,
  cls.config name,
  ...
)
config dict = cls. dict from json file(config file)
This config is used to detect custom pipeline code and enforce the trust check:
# pipeline utils.py:1672
if custom pipeline is None and isinstance(config dict[" class name"], (list, tuple)):
  custom pipeline = config dict[" class name"][0]

load pipe from hub = custom pipeline is not None and f"{custom pipeline}.py" in filenames

if load pipe from hub and not trust remote code:
  raise ValueError(...)
After the check passes, snapshot download then fetches all files and saves them to disk:
# pipeline utils.py:1778
cached folder = snapshot download(
  pretrained model name,
  ...
  revision=revision,
  allow patterns=allow patterns,
  ...
)
Back in from pretrained, the config is read a second time from the downloaded snapshot, and resolve custom pipeline and cls reads the config to re-check if custom code needs to be loaded:
# pipeline loading utils.py:974
def resolve custom pipeline and cls(folder, config, custom pipeline):
  custom class name = None
  if os.path.isfile(os.path.join(folder, f"{custom pipeline}.py")):
    custom pipeline = os.path.join(folder, f"{custom pipeline}.py")
  elif isinstance(config[" class name"], (list, tuple)) and os.path.isfile(
    os.path.join(folder, f"{config[' class name'][0]}.py")
  ):
    custom pipeline = os.path.join(folder, f"{config[' class name'][0]}.py")
    custom class name = config[" class name"][1]

  return custom pipeline, custom class name
If the config points to a .py file, it is imported.

The Vulnerability

hf hub download and snapshot download are two independent HTTP calls to the Hub, both resolving the repository’s default branch (if revision=None) to its current HEAD at call time. There is no atomicity guarantee between them - if the repository is updated between the two calls, they will resolve to different commits and download different content, with no warning displayed to the user.
The trust check in download() operates on the content fetched by hf hub download (commit A). The snapshot download call that immediately follows can silently fetch a newer commit (commit B). The config in the newer commit will be the one parsed by resolve custom pipeline and cls.
Therefore, it’s possible to introduce remote code into the repo between the two calls, bypassing the trust check.
The race window is everything between the two Hub calls inside download():
# pipeline utils.py:1636
config file = hf hub download(...)  # ← sees commit A, trust check passes

# ... filenames processing, pattern building, pipeline is cached check ...
# ~~~ ATTACKER PUSHES COMMIT B HERE ~~~

# pipeline utils.py:1778
cached folder = snapshot download(...) # ← sees commit B, downloads pipeline.py
For the exploit, commit A carries a clean config with class name as a plain string, which causes load pipe from hub to be False and the trust check to pass. Commit B changes class name to a list and adds pipeline.py:
Commit A - model index.json:
{
 " class name": "FluxPipeline",
 " diffusers version": "0.31.0"
}
Commit B - model index.json:
{
 " class name": ["pipeline", "FluxPipeline"],
 " diffusers version": "0.31.0"
}
When from pretrained reads the snapshot after download() returns, config[" class name"] is now a list, pipeline.py exists on disk (fetched by snapshot download), and resolve custom pipeline and cls resolves custom pipeline to the local path of that file. get pipeline class then imports it - with no trust check at this point in the code.

PoC

  1. Create a Hub repo with commit A’s model index.json (plain string class name).
  2. Run DiffusionPipeline.from pretrained("attacker/repo") with a breakpoint set at pipeline utils.py:1778 (the snapshot download call). This is for the window to be large enough to manually respond to it.
  3. When execution pauses at the breakpoint, push commit B: update model index.json to use a list class name and add pipeline.py.
  4. Resume execution.
  5. snapshot download fetches commit B; /tmp/pwned is written during the subsequent get pipeline class call.

Constraints

  • Does not apply when revision is pinned to a specific commit hash - both Hub calls resolve to the same content.
  • Does not apply when loading from a local directory.
  • If all expected files are already present in the local HF cache, download() returns early before reaching snapshot download (line 1767 early-return), closing the race window. The exploit therefore requires a first (or forced) download.

Exploitability

The window between the two calls is very short. Local testing resulted in a window of approximately ~0.5 seconds for the attacker to push the change. This is, of course, unfeasible to accomplish for each and every new download. However, given a popular repo with many downloads per day, one may achieve statistical success by changing the repo’s state every once in a while or every few seconds, with some percentage of downloaders falling on the exact window.

Impact

The vulnerability is a silent RCE - it allows arbitrary code to be loaded through the custom pipeline flow from a Hub repo, with no custom pipeline or trust remote code kwargs. The from pretrained call succeeds and returns a fully functional pipeline.

Fix

Time Of Check To Time Of Use

Weakness Enumeration

CWE-367

Related Identifiers

CVE-2026-45804
GHSA-7WX4-6VFF-V64P

Affected Products

Diffusers