CVE-2026-45804: Diffusers: TOCTOU Trust Remote Code Bypass

Background

This vulnerability is found in the diffusers package - the transformers-equivalent library for diffusion models.

It is found in the DiffusionPipeline.frompretrained flow, which is used to load a pipeline from the HuggingFace Hub.

This function has a trustremotecode guard: if the repository’s modelindex.json references a custom pipeline class defined in a .py file in the repo, the load is blocked unless trustremotecode=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 trustremotecode=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 custompipeline or trustremotecode kwargs passed. The frompretrained call succeeds and returns a functional pipeline.

---

Naive Flow

DiffusionPipeline.frompretrained begins by popping all relevant arguments from kwargs into local variables, then calls DiffusionPipeline.download() to fetch the repo files:

python pipelineutils.py:853 cachedfolder = cls.download( pretrainedmodelnameorpath, ... custompipeline=custompipeline, trustremotecode=trustremotecode, ... )

Inside download(), modelindex.json is fetched first as a standalone file via hfhubdownload:

python pipelineutils.py:1636 configfile = hfhubdownload( pretrainedmodelname, cls.configname, ... ) configdict = cls.dictfromjsonfile(configfile)

This config is used to detect custom pipeline code and enforce the trust check:

python pipelineutils.py:1672 if custompipeline is None and isinstance(configdict["classname"], (list, tuple)): custompipeline = configdict["classname"][0]

loadpipefromhub = custompipeline is not None and f"{custompipeline}.py" in filenames

if loadpipefromhub and not trustremotecode: raise ValueError(...)

After the check passes, snapshotdownload then fetches all files and saves them to disk:

python pipelineutils.py:1778 cachedfolder = snapshotdownload( pretrainedmodelname, ... revision=revision, allowpatterns=allowpatterns, ... )

Back in frompretrained, the config is read a second time from the downloaded snapshot, andresolvecustompipelineandcls reads the config to re-check if custom code needs to be loaded:

python pipelineloadingutils.py:974 def resolvecustompipelineandcls(folder, config, custompipeline): customclassname = None if os.path.isfile(os.path.join(folder, f"{custompipeline}.py")): custompipeline = os.path.join(folder, f"{custompipeline}.py") elif isinstance(config["classname"], (list, tuple)) and os.path.isfile( os.path.join(folder, f"{config['classname'][0]}.py") ): custompipeline = os.path.join(folder, f"{config['classname'][0]}.py") customclassname = config["classname"][1]

return custompipeline, customclassname

If the config points to a .py file, it is imported.

---

The Vulnerability

hfhubdownload and snapshotdownload 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 hfhubdownload (commit A). The snapshotdownload call that immediately follows can silently fetch a newer commit (commit B). The config in the newer commit will be the one parsed by resolvecustompipelineandcls.

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():

python pipelineutils.py:1636 configfile = hfhubdownload(...) # ← sees commit A, trust check passes

... filenames processing, pattern building, pipelineiscached check ... ~~~ ATTACKER PUSHES COMMIT B HERE ~~~

pipelineutils.py:1778 cachedfolder = snapshotdownload(...) # ← sees commit B, downloads pipeline.py

For the exploit, commit A carries a clean config with classname as a plain string, which causes loadpipefromhub to be False and the trust check to pass. Commit B changes classname to a list and adds pipeline.py:

Commit A - modelindex.json:

json { "classname": "FluxPipeline", "diffusersversion": "0.31.0" }

Commit B - modelindex.json:

json { "classname": ["pipeline", "FluxPipeline"], "diffusersversion": "0.31.0" }

When frompretrained reads the snapshot after download() returns, config["classname"] is now a list, pipeline.py exists on disk (fetched by snapshotdownload), and resolvecustompipelineandcls resolves custompipeline to the local path of that file. getpipelineclass then imports it - with no trust check at this point in the code.

---

PoC

1. Create a Hub repo with commit A’s modelindex.json (plain string classname). 2. Run DiffusionPipeline.frompretrained("attacker/repo") with a breakpoint set at pipelineutils.py:1778 (the snapshotdownload 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 modelindex.json to use a list classname and add pipeline.py. 4. Resume execution. 5. snapshotdownload fetches commit B; /tmp/pwned is written during the subsequent getpipelineclass 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 snapshotdownload (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 custompipeline or trustremotecode kwargs. The frompretrained call succeeds and returns a fully functional pipeline.